Hi Thomas,

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!
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).

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());
}
...
}

Attachment: OJBAcceptLocks.zip
Description: Zip compressed data

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to