[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ojb-user
Subject:    Re: ObjectEnvelopeTable.reorder() problems
From:       Colin Kilburn <colink () accesstec ! ca>
Date:       2005-03-29 19:32:40
Message-ID: 4249AD58.10705 () accesstec ! ca
[Download RAW message or body]

Thanks Armin.   flush() fixes the problem.   I just tried upgrading to 
1.0.2, but that doesn't appear to fix the problem.   I can live with the 
flush() workaround until that is solved.

Thanks again, I appreciate your help.

Colin

Armin Waibel wrote:

> Colin Kilburn wrote:
>
>> Hi Armin, thanks for the response.
>>
>> I'm using OJB 1.0.1.   I've never noticed the TransactionExt.flush() 
>> method.   Calling it does seem to fix the problem.   I do have 2 
>> questions, however:
>>
>> 1. the javadoc says flush() is very similar to 
>> Transaction.checkpoint().   How do they differ?
>
>
> flush() only writes the objects to DB, connection still remain.
> checkpoint() write objects and commit the connection
> both methods keep the locks.
>
>> and would it be preferable to call checkpoint() instead?
>
>
> Nope, because after checkpoint no rollback is possible.
>
> (calling checkpoint() seems to
>
>> work as well)
>>
>> 2. is calling flush() expensive? 
>
>
> Not really, compared with the write to the DB.
>
>> (I have a wrapper around all my lock() calls, would it be excessive 
>> to call flush() after every lock(), even when it's not needed?
>
>
> In this case I would expect an performance decrease. A performance 
> test case should shed some light on this.
>
> In OJB 1.0.2 the odmg-api is completely refactored and many bugs are 
> fixed. I assume that your bi-directional problem will be solved in 
> this version (take care of new metadata settings and properties).
>
> regards,
> Armin
>
>
>>
>> Colin
>>
>> Armin Waibel wrote:
>>
>>> Hi Colin,
>>>
>>> which version of OJB do you use?
>>> Did you try to use TransactionExt.flush() calls to separate the calls
>>>
>>> > beginTxn();
>>> >
>>> > B b = new B();
>>> >
>>> > a.setCurrentB(b);
>>> >
>>> > lock(b);   // corresponds to an INSERT into B's table
>>>
>>> ((TransactionExt) tx).flush();
>>>
>>> > lock(a);   // corresponds to an UPDATE on A's table, with a FK 
>>> reference
>>> > to the just-inserted B
>>> >
>>> > commitTxn();
>>>
>>>
>>> regards,
>>> Armin
>>>
>>>
>>> Colin Kilburn wrote:
>>>
>>>> Hi All,
>>>>
>>>> I'm currently having a problem with reordering of written objects 
>>>> done by the org.apache.ojb.odmg.ObjectEnvelopeTable.reorder() 
>>>> method.  I have implicit locking off, and I always "lock" objects 
>>>> in the order they would have to in order to maintain referrential 
>>>> integrity.   That is, I don't think I would have a problem if I 
>>>> could disable "reordering" before committing a transaction.   Is 
>>>> there a way to disable reordering?
>>>>
>>>> The following is an attempt to describe my situation:
>>>>
>>>> I currently have a bi-directional relationship between two 
>>>> objects.   Say I have two classes A and B:
>>>>
>>>> class A {
>>>>   private B currentB;
>>>> }
>>>>
>>>> class B {
>>>>   private A a;
>>>> }
>>>>
>>>> An A can have multiple B's, but it keeps a pointer to the current 
>>>> B, which is updated every time a new B for that A is created.   
>>>> This bi-directional relationship seems to cause problems for the 
>>>> ObjectEnvelopeTable.reorder() method.   I.e., when doing the 
>>>> following (pseudocode):
>>>>
>>>> beginTxn();
>>>>
>>>> B b = new B();
>>>>
>>>> a.setCurrentB(b);
>>>>
>>>> lock(b);   // corresponds to an INSERT into B's table
>>>> lock(a);   // corresponds to an UPDATE on A's table, with a FK 
>>>> reference to the just-inserted B
>>>>
>>>> commitTxn();
>>>>
>>>> What ends up happening is that the UPDATE is happening before the 
>>>> INSERT, which fails because currentB's id is not yet defined.   By 
>>>> playing with the order that I lock those objects and others within 
>>>> the transaction, I can sometimes get them to go in the right order, 
>>>> but this is hokey.  The problem resurfaces when tearing down my 
>>>> unit tests, as the reordering at delete time can also get messed 
>>>> up.   The following thread describes a similar problem to mine.
>>>>
>>>> http://www.mail-archive.com/ojb-user@db.apache.org/msg05317.html
>>>>
>>>> Anyway, I think if I could disable reordering, perhaps in the 
>>>> OJB.properties or something, I would cease to have this problem.   
>>>> The other obvious (but not really acceptable) solution would be to 
>>>> do these writes in separate transactions, making reorder()'s 
>>>> effects harmless.
>>>>
>>>> Thanks in advance for any help,
>>>> Colin
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]