> How can he control that another thread does not query for one 
> of the objects
> he has loaded ?
> 
> example:
> 
> TX1 starts               (cache: <empty>)
> TX1: finds A           (cache: A )
> TX2: starts              (cache: A )
> TX1: modifies A      (cache: A' )
> TX2: finds A           (cache: A' )   ...TX2 now have a 
> direct reference to
> A'  that cannot be changed by OJB
> TX1: cancel transaction (cache: ? (I guess: A'))
> TX2: commits something based on A' even though it should have been A
> 
> How do you ensure that this does not happen with a singleton 
> cachestrategy ?

You need to prevent this situation yourself.

If a transaction is canceled this is what I currently do to prevent
data-integrity problems:

   1. Clear the cache.
   2. Refresh the state of all objects involved in the transaction from the
database. I do this in the implementation of TransactionAware.afterAbort().
OJB automatically calls this method when an ODMG transaction is
cancelled/aborted. Your persistent objects need to implement the
TransactionAware interface.

Step #1 prevents invalid data from being re-read in step #2. Step #2 ensures
that TX2 does not read invalid data. For this to be true, though, you need
to set your transaction isolation level to 'read-committed'.

IMO, you only need to clear the cache if a transaction aborts. If you handle
the above situation properly, you can still leverage a single, global cache.


> 
> > If you use the ODMG layer, it does the work of committing 
> all changed
> > objects (since by write-locking an Object it is registered for later
> > update to the db)
> 
> Yes, but does the LockManager removes those objects that is 
> cancellede ?

OJB DOES remove the aborted objects from the cache. Not the LockManager,
though. It is the OJB classes that implement ModificationState that remove
aborted objects from the cache (if the modification state is not clean). 

When a transaction aborts, though, I clear the cache (step #1 above) just to
ensure that I'm truly refreshing all objects and relationships from the
database.

-Richard




Notice:  This e-mail and any attachments are intended only for the
individual or company to which it is addressed and may contain information
which is privileged, confidential and prohibited from disclosure or
unauthorized use under applicable law.  If you are not the intended
recipient of this e-mail, you are hereby notified that any use,
dissemination, or copying of this e-mail or the information contained in
this e-mail is strictly prohibited by the sender.  If you have received this
transmission in error, please return the material received to the sender and
delete all copies from your system.  Thank you.

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to