> > I just tested this and I correctly get a "key not found" error.  
> > That's because
> > mySession2 hasn't crossed a transaction boundary.  Just as in 
> > GemStone, the
> > view of the db for any client is only refreshed upon a commit or 
> > abort.  Since
> > you didn't do this for mySession2, the correct response is "key not 
> > found"
> > which is what I got.
> 
> That's interesting, because earlier in the test, I didn't need to cross 
> a transaction boundary to see this.  That is:
> 
> "I try modifying the root in mySession2, and then inspecting it in 
> mySession.  The change came across.  Cool."

Here is why.  When you read objects, they get cached in a
WeakIdentityKeyDictionary and your "program" will either "care" about them
(e.g., reference them) or not.  If it doesn't care about them, then changes to
those objects by other sessions may or may not, depending on whether a
GC/finalize has happened) will either be reflected upon the next read of that
object or not.  If the WeakKey dictionary has been finalized, you will see the
new "updated" value of that object even though you didn't cross a transaction
boundary.

But, if your program *did* care about those objects, meaning they are
referenced, then you *won't* see any changes by other clients until you cross a
transaction boundary.

I hope I made any sense on that..