<div dir="ltr"><div class="gmail_quote"><div>Hi Eliot,</div><div><br></div><div><div>Thanks for your patience with our questions while we get up to speed understanding how to use this new feature.</div><div></div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It's a super-low-level error that ought to be handled really really closely to where the error was raised. As Eliot mentioned, the VM can't know the circumstances and just raises it; the the closest possible handler should be in place that *does* know the circumstances. That way Chris gets to spot that is it a database issue and handle things properly, including likely raising a new error for higher level code.<br></blockquote><div><br></div><div>As I've already mentioned what one can do, and the VisualWorks version does do, for GemStone-style persistence, as add behavior to the exception so one can specify a per-object response.</div><div><br></div><div>So if the exception is unhandled, then before it raises an UnhandledError it checks an identity dictionary, which maps object to message, and if the read-only object that was the cause of the error is in the dictionary, instead the exception performs the message with the object as an argument.  So a database layer can add the objects it is managing to the map in ModificationForbidden, and mark them as read-only.  Then any and all attempts at modifying these objects will cause the database man ager to be notified. </div></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> So very simply we can have a pluggable solution that allows different clients to map the exception into different responses as desired. </div></div></div></div></div></blockquote><div><br></div><div><div><div>But an object in your db table could easily be an Array literal held by a CompiledMethod, not expected to change, but persistent by reference nonetheless.  So if the application did then modify it accidentally, instead of Forbidden protection, your DB manager would happily modify it.  It's this separation of use-cases is all what the question was about I think, not a big deal, we've lived with unprotected CM literals for this long already, and I've never needed WriteBarrier for anything other than a DB.</div><div><br></div><div>However, I still don't see the path for how to use this in a complex multi-db Magma application with oblivious objects (e.g., Morphs).  It's not something any of the GemStone clients I consulted at as developer or DBA ever had to contend with either, but perhaps not something you're targeting.  Squeak is a different animal...  I will stay tuned here and watch for the answers as they unfold...</div></div></div><div><br></div><div> - Chris</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>So can we please stop wasting time discussing this and get on with implementing it?  The GemStone folks have understood how to manage ModificationForbidden for years and the use of it has been in production.  We simply need to catch up.  We're nearly there.   </div></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> </div></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Please don't make me explain this idea once again ;-)</div></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br>></div><div>><br>> Given having a handler really close to the source, perhaps we are better off keeping it non-resumable and using one of the other approaches to continuing like #retryUsing: (ExceptionTester>>#simpleRetryUsingTest is the only example in the clean image) ? </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
tim<br>
--<br>
tim Rowledge; <a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" rel="noreferrer" target="_blank">http://www.rowledge.org/tim</a><br>
Strange OpCodes: BFM: Branch on Full Moon<br>
<br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div></div></div>
<br>
</blockquote></div></div>