> > 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'.
Ok - I do not understand how step #1 and #2 can prevent TX2 from getting a hold on A' ? It is because read-commited will not allow me to read modified objects ? If that is required then the performance would be degraded as each thread working on the same object has to wait for a read lock even though it could just get a fresh copy from the database which is still valid (because thread 2 has not yet commited) if just the transaction had its own cache! Then there would be no such problems :) > 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). Yes - but this does not remove the other transaction reference to those objects, right?! And this requirment of implementing ModificationState is not good :( > 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. Here I totally agree .... just don't find it very attractive to clear the cache as the objects might be used in other ongoing transactions!! (or are you just removing the objects touched/read/written in the failed transaction ? - if yes, how about related transactions ? Are they aborted too ?) /max -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
