You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Martin Davidsson <ma...@gmail.com> on 2005/05/17 17:50:10 UTC
Write lock where Read expected
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.
Also, were there ever any plans to create a DSetImpl_2... similar to
the old DListImpl_2? Thank you!
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: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Write lock where Read expected
Posted by Martin Davidsson <ma...@gmail.com>.
Armin,
One more question if you don't mind. I noticed your post at http://
www.mail-archive.com/ojb-user@db.apache.org/msg13624.html. I believe
I'm having the same problem as Steve Clark. I checked out the branch
you described via cvs -d:pserver:anoncvs@cvs.apache.org:/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: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Write lock where Read expected
Posted by Martin Davidsson <ma...@gmail.com>.
Thanks Armin. Looking forward to version 1.0.4 :)
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: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Write lock where Read expected
Posted by Armin Waibel <ar...@apache.org>.
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: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org