Re: query before commit problem
Hi Charles, Charles Anthony wrote: Hi, Someone asked for this recently, and I'm afraid I was too busy to reply. No problem :-) When you lock an object (for update), it is *before* you make any changes to it. How can OJB know when to "automatically" flush changes to the database ? It can't; you have to tell it to. The same applies to locking an object for create; you can lock an object for create, *then* set the values on the object - it is only at commit/flush time that we know what the complete changes are... Yes you're right. But my problem is a little bit different. I've got 2 EJB's let's say A and B. B does all OJB related stuff. A is a statefull session bean. A part of it is I generate session data and store them at the DB. At the end of the session I'm searching for the data and delete them. As long as A is bean managed everything works fine but if A is container managed the commit of the insert of the session data is at the end of the whole session and so the query to delete the data fails and AFTER that the session data are inserted. I tried to set B to RequiresNew. So the first insert call should get a commit after it's completion and the data should be at the db when querying at the second delete call. This did not change anything. Either JBoss has a problem at the generating of the inner session or OJB is using the outer session any time although there is a inner one. Cheers, Charles best regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: query before commit problem
Hi, Someone asked for this recently, and I'm afraid I was too busy to reply. When you lock an object (for update), it is *before* you make any changes to it. How can OJB know when to "automatically" flush changes to the database ? It can't; you have to tell it to. The same applies to locking an object for create; you can lock an object for create, *then* set the values on the object - it is only at commit/flush time that we know what the complete changes are... Cheers, Charles -Original Message- From: Guido Beutler [mailto:[EMAIL PROTECTED] Sent: 16 September 2003 08:38 To: OJB Users List Subject: Re: query before commit problem 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. >
Re: query before commit problem
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 mess
Re: query before commit problem
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);
> >>>>
> >>>> Que
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);
//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);
//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]
Re: query before commit problem
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);
> >>//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);
> >>//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]
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);
>>//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);
>>//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]
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);
//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);
//loaded!=null now! loaded==q!
t.commit();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
