| cbeams 2007-08-07, 7:11 pm |
|
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
|