From: Max M. <max...@ma...> - 2002-11-04 18:02:00
|
Hi Camille, > I have borrowed a part of ERCStampedEnterpriseObject's implementation > in a class I have called OFDatedEntity. The user of this abstract > class is to provide EOs with optimistic locking handling : In > EOModeler, only two rows have the lock enabled, the primary key row, > and the lastModified row. If you take that approach then you just need to make sure that you have all of your inverse relationships modeled so that your eo will always be "touched" when a relationship to it changes, else you could not detected a relationship change and stomp over a previous commit. > This row (last modification date) is in the case of > ERCoreBusinessLogic framework is a TIMESTAMP (or DATETIME for those > who prefer). > > The problem is that TIMESTAMP datatype is no more precise than the > second. > The minimum precision we could expect from such functionality would be > the milli or better, the micro-second. Thus something based in a > datatype that has different precisions/implementations over different > databases is not a good solution. > > Secondly, in the implementation of ERCStampedEnterpriseObject's, a > mutable dictionary (_datesPerEcID) keeps references to last > modification dates vs. editing contexts. If an editing context is > dealloc'ed the entry in the mutable dictionary is never removed (this > is a potential memory leak). > If I understood correctly, _datesPerEcID holds the date of the last > modification and applies the same modification date to all modified > enterprise objects in the same editing context. The dictionary does not hold a reference to the editing context, instead it holds the system unique hash code of the editing context. You are correct that this dictionary will continue to grow over time and not be cleaned up. We could correct this issue in three ways a) right now we hold references to all the editing contexts created for a session until that session has been garbage collected, this was done to avoid the "attempt to message eo that has had their editing context freed", so when this dictionary is freed we could post a notification that the editing context will be freed, then in ERCore we have a handler that removes the entry for that ec from the dictionary b) we use a WeakHashMap with a direct reference to the editingcontext c) we subclass EOEditingContext and post a notification in the finalize() method of the ec. Personally I would lean towards a) or b). > If we used an integer that would be incremented every time it was > updated, we would not need to use the _datesPerEcID and there would be > no dependancy over datetime (timestamp) precision. If you just wanted a transaction id that is incremented and set on all of the objects then you could actually just use an editing context delegate and in editingContextWillSaveChanges just increment the transaction id and set that value on all inserted, updated and deleted objects in the editing context. Might be a simpler solution. Regards, Max |