So regarding Collection Proxy Locking, I think there is a reasonable solution:
1. Maintain a list of information about Collections that are locked as proxies, in
this list put:
a. A query that will return the list of id's for objects that are locked, ie
"SELECT ... FROM FOO_TABLE WHERE PARENT_ID = BAR", decompose this from
string based representation for better performance.
2. During the locking phase of an object, do the following:
a. Check if the CollectionProxyLockedList has any elements
b. Check if the CollectionProxyLockedList has any elements for this Table type
(FOO_TABLE)
b. Check if the object being locked participates in the many side of a
one-to-many.
c. if there exists a locked collection on the table you want to lock the
object for, execute the query that checks if this object is locked, ie
"SELECT COUNT(*) FROM FOO_TABLE WHERE PARENT_ID IN <ALL PARENT ID's
FOR COLLECTIONS MAPPED TO THIS TABLE THAT HAVE PROXIED COLLECTIONS LOCKED> AND
ID=<requested for lock object id>"
d. if result is not 0, there is a lock on that object.
I think this should be reasonably fast if implemented correctly, and could still be
implemented to work with the persistent lock map impl as well as the in-memory lock
map. It would depend on users knowing how their application works, and then
configuring proxied collections properly.
thoughts?
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
