Hi Thomas,
I found that adding a flag to the collection descriptor and reference descriptor wasn't quite the right approach. As I construct a new graph, I must query my large graph (the one that doesn't change much and shouldn't propagate locks), and so a read lock is obtained on one of these objects which gave me the large delay that I must avoid (ImplicitLocking=true). So I added a flag "acceptLocks" (default=true) to the class descriptor itself which is checked in org.apache.ojb.odmg.TransactionImpl.lock(...) (see below).I could submit the changes on the latest cvs head for your perusal if you like.
Just post your stuff, I'll review it and check it in!
It's maybe a little cleaner this way: only the targetted class needs to be labelled, not all references to it.
Affected files:
repository.dtd
repository_user.xml
org.apache.ojb.broker.metadata.RepositoryTags
org.apache.ojb.broker.metadata.RepositoryElements
org.apache.ojb.broker.metadata.ClassDescriptor
org.apache.ojb.broker.metadata.RepositoryXmlHandler
org.apache.ojb.odmg.TransactionImpl
Hope this is helpful.
Phil
<class-descriptor
class="A"
table="A_TABLE"
accept-locks="false"
>
public void lock(Object obj, int lockMode) throws LockNotGrantedException
{
ClassDescriptor cld = this.getBroker().getClassDescriptor(obj.getClass());
if (!cld.isAcceptLocks())
{
if (log.isDebugEnabled())
log.debug("skipping lock on class: " + cld.getClassNameOfObject() + " object " + obj.toString());
return;
}
else
{
if (log.isDebugEnabled())
log.debug("proceeding with lock on class: " + cld.getClassNameOfObject() + " object " + obj.toString());
}
...
}
OJBAcceptLocks.zip
Description: Zip compressed data
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>