db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Davidsson <martin.davids...@gmail.com>
Subject Re: Write lock where Read expected
Date Wed, 18 May 2005 15:49:07 GMT
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


Mime
View raw message