Re: query before commit problem

[Guido Beutler]

Hi Armin,

what do you think to make it configurable. For managed enviroment
the default would be a write through (or call it auto flush).
I can not access the cvs so I can not test your new Tx implementation. :-(
best regards,

Guido

Armin Waibel wrote:

Hi Guido,

tx.checkpoint() is not allowed in managed
environments, because it does commit the
'underlying' connection (commit the current tx).
Allowed to use is ((TransactionExt) tx).flush()
(new introduced interface ExtTransaction is not part
of rc4 - use CVS)
this perform object operations on connection without
commit the connection/tx.
regards,
Armin
----- Original Message -----
From: "Guido Beutler" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Monday, September 15, 2003 1:13 PM
Subject: Re: query before commit problem
 

Hi,

how to do it in managed enviroment?

transaction.checkpoint()

throws a not supported exception.

best regards,

Guido

Jair da Silva Ferreira J�nior wrote:

   

Hi,
  Thank you Thomas and Charles for your fast answers. I think I'll
     

use
 

transaction.checkpoint() as Charles pointed.
  By the way, don't you think this would be a nice feature to be
     

added to
 

a future OJB version? Say, when an object is persisted insinde a
     

transaction
 

it would be nice if any query runned inside that transaction could
     

"see"
 

that object.

Sincerely,
  Jair Jr
----- Original Message -----
From: "Charles Anthony" <[EMAIL PROTECTED]>
To: "'OJB Users List'" <[EMAIL PROTECTED]>
Sent: Friday, September 12, 2003 1:52 PM
Subject: RE: query before commit problem


     

Hi,

As Thomas says, this is by design. However, you can force the
       

transaction
 

       

to

     

flush all object changes to the database, without committing the

       

underlying

     

database connection :

In RC4, you can use Transaction.checkpoint() e.g. t.checkpoint();

After RC4 (i.e. in CVS), you should be able to cast the transaction
       

to
 

TransactionExt and invoke TransactionExt.flush

e.g. (TransactionExt) t).flush()

HTH,

Cheers,

Charles.



       

-----Original Message-----
From: Thomas Mahler [mailto:[EMAIL PROTECTED]
Sent: 12 September 2003 17:48
To: OJB Users List
Subject: Re: query before commit problem
Hi Jair,

ODMG transaction write to the db only on tx.commit.
Thus q is not persistent in the database when you perform the
first query!
All queries (also ODMG OQL!) are executed against the
database. So it's
obvious that loaded != q after your query.
after commiting the transaction q is stored in the DB and the
         

second
 

query does find it.

Works as designed.

-Thomas

Jair da Silva Ferreira J�nior wrote:

         

Hi,
  I am using ojb1.0_rc4, ODMG api with OJB queries and
           

mysql4. The problem is that when I persist an object and run a
identity query looking for the persisted objet the query
returns null. This only happens when I persist the object and
execute the query in the same transaction. Is this behaviour
correct or is this a bug?
         

  I added some example code in the end of this email for

           

better understanding.

         

  Thanks for your help.

Sincerely,
  Jair Jr
Example code:

void doSomething(){
 Transaction t=implementation.newTransaction();
 t.begin();
 Question q=new Question();
 t.lock(q,t.WRITE);
 q.setStatement("a statement");
 q.setNumber(10);
 q.setSubject(Subject.PHYSICS);
 q.setCorrectAlternative(Alternative.A);
 Question example=new Question();
 example.setId(q.getId());
 QueryByIdentity query=new QueryByIdentity(example);
 Question loaded=(Question)
           

((HasBroker)t).getBroker().getObjectByQuery(query);

         

 file://loaded==null !!! why? Shouldn't it be: loaded==q?
 t.commit();
 t=implementation.newTransaction();
 t.begin();
 query=new QueryByIdentity(example);
 loaded=(Question)
           

((HasBroker)t).getBroker().getObjectByQuery(query);

         

 file://loaded!=null now! loaded==q!
 t.commit();
}
           

---------------------------------------------------------------------
       

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


         

This email and any attachments are strictly confidential and are
       

intended
 

solely for the addressee. If you are not the intended recipient you
       

must
 

not disclose, forward, copy or take any action in reliance on this
       

message
 

or its attachments. If you have received this email in error please
       

notify
 

the sender as soon as possible and delete it from your computer
       

systems.
 

Any views or opinions presented are solely those of the author and
       

do not
 

necessarily reflect those of HPD Software Limited or its affiliates.

At present the integrity of email across the internet cannot be

       

guaranteed

     

and messages sent via this medium are potentially at risk.  All
       

liability
 

is excluded to the extent permitted by law for any claims arising as
       

a re-
 

sult of the use of this medium to transmit information by or to
HPD Software Limited or its affiliates.


       

---------------------------------------------------------------------
     

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]


   



---------------------------------------------------------------------
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]