This is certainly an interesting thread. Can we just clarify what we
think the correct behaviour should be from Castor?
In my opinion, Castor should not return created objects via OQL or any
other means until they are committed. That's because in Castor's world,
objects do not exist until they are committed to the database.
I really do believe that otherwise this could cause isolation problems -
it's like withdrawing money from your bank account with an uncleared
check! It might be OK to allow OQL to return the object within the
transaction that created it (from within the transactional cache say),
but not within other transactions. But within a single transaction, you
should have access to the created object as it should be available as a
variable within the scope of the method the transaction is running
within - there should be no need to get it from Castor. Transactions
don't span multiple threads so there are plenty of ways you can get
access to the created object.
Imagine this scenario:
Transaction 1
-Start transaction
-Create "objectX"
-Rollback transaction
Transaction 2
-Start transaction
-Load "objectX" via any OQL query
-Change "objectX"
-Commit transaction
What if the sequence was this (in a multithreaded scenario):
T1 start
T1 create "objectX"
T2 start
T2 load "objectX" via any OQL query
T2 change "objectX"
T2 commit
T1 rollback
This will surely leave your system in an inconsistent state. T2 is a
dirty read.
Am I missing something here? I welcome your views.
Cheers,
Patrick
-----Original Message-----
From: Werner Guttmann [mailto:[EMAIL PROTECTED]
Sent: 10 November 2004 22:15
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] [jdo] Reading, in the same transaction, a data
just created (reading via oql query)
Bruce et alias,
after some investigation on my side, I come to believe that whether the
cache is used or not does not make a difference in this case. Why ? If
somebody
calls Database.create() as part of as transaction, a cache entry will
not be added until execution of the commit phase. In my tests, I tried
to turn the
performance caches on and off, and it simply didn't make a difference.
As already mentioned in a separate reply, I came to believe that this
might have been fixed with the 0.9.6 release candidate, but I cannot pin
down the
bug number right now. All tests I have been running complete
successfully, irrespective of whether the id is part of the OQL query or
not.
Werner
On Wed, 10 Nov 2004 14:19:05 -0700, Bruce Snyder wrote:
>
>SYLVIE PALLUEL wrote:
>
>> I don't know if this can help you, but I made another test with an
OQL
>> pass-thru, and I get the new object before the commit phase.
>
>It seems to me that using pass through SQL should only work if you are
>using autocommit. Are you using autocommit? What database are you
using?
>
>> Is there something special to do to enable the OQL query to see the
objects
>> created inside the current transaction?
>
>There's nothing special that needs to be done. Just as Patrick stated,
>OQL queries do not look at the cache before going to persistence. This
>is different from the db.load() method which actually does look at the
>cache first.
>
>Bruce
>--
>perl -e 'print
>unpack("u30","<0G)[EMAIL PROTECTED]&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
>
>The Castor Project
>http://www.castor.org/
>
>Apache Geronimo
>http://geronimo.apache.org/
>
>
>
>-----------------------------------------------------------
>If you wish to unsubscribe from this mailing, send mail to
>[EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
>
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
