On Aug 7, 2007, at 12:11 PM, Andy Jefferson wrote:
 
> 
>
> "detachAllOnCommit" will transition instances to detached *at
> commit*. You
> have no commit here (using nontransactionalRead ?). If you have
> tx.begin(),
> tx.commit() around it then its definitely fine. Nothing in the spec
> definition of "detachAllOnCommit" implies (to me) that queries run
> with
> non-tx read will do the detach.

Sorry - my bad.  I meant to wrap the above in a transaction, thus
detaching the enlisted foo instance.

> 
>
> "foo" : detached-clean -> detached-dirty
> 
>
> "foo" : detached-dirty -> persistent-clean
> 
>
> "foo" : persistent-clean -> detached-clean
> 
>
> "foo" : detached-clean -> detached-dirty
> 
>
> "foo" : detached-dirty -> persistent-clean

I'm with you until this last one...  It would transition from
persistent-clean to detached-clean upon committing the transaction,
right?  If so, then we're aligned...

> 
>
> No. If referring to the same PM, the object would have been removed
> from L1
> cache at detach. The exception I was referring to was if you did a
> separate
> PM.detachCopy() or detached it from a different PM and *then* tried
> to attach
> to the same PM as one that already had it.

Aha..  not knowing how the L1 cache really works, I didn't know that
instances get evicted on detach.  This would work, it seems.  More to
the point, my application uses a new PM for each successive
makePersist() call, so there's even less chance of the instance
already existing in the L1 cache.

Sounds like we're on the right track...

- Chris

[ Post a follow-up to this message ]