<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Mar 18, 2010, at 9:19 AM, Eliot Miranda wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Thu, Mar 18, 2010 at 8:17 AM, James Foster <span dir="ltr">&lt;<a href="mailto:Smalltalk@jgfoster.net">Smalltalk@jgfoster.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">
<div class="im">On Mar 17, 2010, at 11:28 PM, Igor Stasenko wrote:<br>
<br>
&gt; the above is an example when object, recorded as an immutable one,<br>
&gt; then mutated outside a DB transaction. So db can't capture the attempt<br>
&gt; to modify it. What GemStone doing to handle this?<br>
<br>
</div>Actually, GemStone traps object modification at the byte-code level in the VM so does not rely on immutability to be informed of a modification.<br></blockquote><div><br></div><div>Not preferrentially. &nbsp;It used to do that, but it is a problematic approach. &nbsp;The preferred implementation is above VM-supported per-object immutability. &nbsp;We've recently discussed this topic, I think on the Pharo list. &nbsp;Martin McClure of GemStone wrote excellent posts describing the implementations, their trade offs, and the higher levels of the framework which support installing managers for the immutability exception that supports multiple frameworks using immutability concurrently.</div></div></blockquote><div><br></div><div>Sorry. I was discussing GemStone's server VM, not the replication/proxy activity in a client Smalltalk remote from GemStone (such as GBS in VW).</div><div><br></div><div>James</div></div></body></html>