Hi Scott, Scott Howlett wrote:
I recently improved this mechanism to avoid checking objects of already dirty marked objects.Hello,I noticed that even with implicit locking turned off, a bunch of extraneous DB activity occurs when you commit an ODMG transaction that has read-locked objects with collection proxies. ObjectEnvelopeTable.commit() works in three phases: 1. Run through all active objects and get write locks on them if they have been modified.
2. Reorder all active objects in order of referential dependency. This step causes unnecessary DB activity when committing a transaction in which no modifications have been performed. 3. Run through the reordered list again, committing changes to each object and invalidating it from the PB cache. I just inserted a check in step 1 so that step 2 is skipped when no objects need to be committed.
Good idea! I will review your code and integrate it into the codebase!
I think there are more areas for improvement, but I have not tried them yet: 1. reorder and commit only those objects that need committing.
Good idea too!
2. If implicit locking is turned off, don't bother comparing the old and current state of the object for the purpose of implicitly getting a write lock - if the user tweaked an object without getting a lock first, just ignore the change (maybe in debug mode do the check anyway and throw an exception?)
Another good idea!
Yes, your ideas make sense.Please let me know if these changes are reasonable. Since I've only been fooling with the ODMG stuff for a day I'm not very confident that I've considered all the possible consequences.
As I'm in a "add some nice hacks to ODMG" I'll sit down and try to get something done tonight...
thanks for inspiration.
Thomas
Thanks, Scott Howlett -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
