Armin,
One more question if you don't mind. I noticed your post at http://
www.mail-archive.com/[email protected]/msg13624.html. I believe
I'm having the same problem as Steve Clark. I checked out the branch
you described via cvs -d:pserver:[EMAIL PROTECTED]:/home/
cvspublic co -r OJB_1_0_RELEASE db-ojb. Using the JAR that results
from that source seems to break other things, however, but I think
it's related to the fact that inheritance is not stable, as you
pointed out.
Steve said, "If I put entries in both indirection tables by hand,
then the object is materialized correctly." My question is, do you
have an example of how this manual construction is achieved? Thanks
for your help!
-- Martin
On May 17, 2005, at 7:25 PM, Armin Waibel wrote:
Hi Martin,
Martin Davidsson wrote:
Hello,
I upgraded to OJB version 1.0.3 and started seeing some new
exceptions during run-time. OJB said it was unable to perform a
WRITE lock on some of my objects. I didn't expect a WRITE lock to
be necessary at all in this particular situation since I was
pulling up a page on my site that doesn't perform any
modifications to the database. I traced the source and got to the
org/apache/ojb/odmg/oql/ OQLQueryImpl.java file. On line 329 we
have the statement "tx.lockAndRegister(rt, Transaction.WRITE,
true);" despite multiple comments above it pointing to the fact
that a READ lock should occur. I tried changing Transaction.WRITE
to Transaction.READ and my problems went away, but perhaps this
statement should in fact be the way it's pasted below and it's
just that the comments are throwing me off. I was wondering if
anybody on the list could set me straight.
thanks much! You are right, this changed between <=1.0.1 and 1.0.3.
The correct setting is READ. Will fix this in CVS.
Also, were there ever any plans to create a DSetImpl_2... similar
to the old DListImpl_2? Thank you!
What will be the advantage of such a DSetImpl_2? What's wrong with
DSetImpl?
In 1.0.3 the old DListImpl was replaced by a enhanced/refactored
version of old DListImpl_2 and the old DSetImpl was replaced by a
refactored version working similar as DListImpl.
regards,
Armin
Here is the relevant function in context:
protected void performLockingIfRequired(
TransactionImpl tx,
PersistenceBroker broker,
ManageableCollection result)
{
// if tx is available and implicit locking is required,
// we do READ-lock all found objects
if ((tx != null) && tx.isImplicitLocking() && tx.isOpen())
{
// read-lock all resulting objects to the current
transaction
Iterator iter = result.ojbIterator();
Object toBeLocked = null;
try
{
while (iter.hasNext())
{
toBeLocked = iter.next();
RuntimeObject rt = new RuntimeObject
(toBeLocked, tx, false);
tx.lockAndRegister(rt, Transaction.WRITE, true);
}
}
finally
{
tx.lockAndRegisterCleanup();
}
}
}
-- Martin Davidsson
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
