It needs to be noted that as of this change, anyone expecting the
old/default behavior (ie accept-locks="true") will need to make sure
they are using the latest repository.dtd, as this is where the default
lives - without it everything acts as accept-locks="false" and
persisting new instances with Transaction.lock() will not persist
anything. I just spent about 8 hours trying to figure out why my code
suddenly failed....
I hate to complain, 'cause everyone here works hard to create a good
product and is very helpful, but It would be helpful if "breaking"
changes that require user intervention (ie copying dtds) were
"announced" to the list to prevent just this kind of problem.
>From this I have two questions
1 - could the "fallback default" be coded somewhere else that would
prevent this kind of failure due to dtd change?
2 - If I understand this change correctly, then a class marked
accept-locks="false" can never be locked, which also follows can never
be persisted. (thus why my code started to fail!) Is this correct? My
experimental code bears this out. This would seem to only be effective
for "read-only" data, being written from outside of OJB/ODMG - perhaps
PB can get around this?
On Sat, 2002-11-30 at 10:39, Thomas Mahler wrote:
> Hi Phil,
>
> Phil Warrick wrote:
> <snip>
>
> > 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.
> >
>
> Well done! The solution looks really elegant this way!
> I just checked it into CVS.
>
> Thanks,
> Thomas
>
>
> > 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());
> > }
> > ...
> > }
> >
> >
> > ------------------------------------------------------------------------
> >
> > --
> > 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]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
