Hello,
I've created a bug report at http://bugzilla.exolab.org - Bug 1793.
I'm trying to reproduce my problem on a junit test case, as suggested me
Werner.
I'll send it to you if there's something special.
Sylvie.
___________________
CREDI RA
Sylvie Palluel
[EMAIL PROTECTED]
___________________
> -----Message d'origine-----
> De�: Werner Guttmann [mailto:[EMAIL PROTECTED]
> Envoy�: jeudi 11 novembre 2004 21:23
> ��: [EMAIL PROTECTED]
> Objet�: Re: [castor-dev] [jdo] Reading, in the same transaction, a data
> just created (reading via oql query)
>
> Ralf, Patrick et alias,
>
> nothing to add, to be honest. Let's open a bug and close it immediately,
> as I simply cannot reproduce Sylvie's problems ... I will attach the tests
> I use as
> soon as the bug has been created, so that somebody else can run then
> against 0.9.5.3, and see whether this makes a difference. Though This most
> likely is not going to be me, as I am moving flats this weekend.
>
> Werner
>
> On Thu, 11 Nov 2004 11:54:13 +0100, Ralf Joachim wrote:
>
> >
> >Patrick,
> >
> >I agree with your definition. The changes to an object or the objects
> >created should only be visible inside the transaction that changed or
> >created before commit. Other transactions don't see the changes or the
> >new object utile they are commited.
> >
> > From my experience that's the way databases are handling this situation
> >and also users of castor would expect.
> >
> >Sylvie could you please open a bug report for this?
> >
> >See also my comment inline.
> >
> >Patrick van Kann schrieb:
> >> 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.
> >A transaction would not span multiple threads but between the creation
> >and the access to the JDO in one thread and transaction could be a lot
> >of code. For example the JDO is created by one object and accessed by
> >another object that do not know from each other. In some cases it would
> >cause a lot of problems to pass the object created to all places it
> >needs to be accessed.
> >>
> >> 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
> >As creation of objectX is not commited by T1, for T2 it looks like no
> >objectX is available at load. That's what transaction isolation is for.
> >>
> >> 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
> >
> >--
> >
> >Syscon Ingenieurb�ro f�r
> >Me�- und Datentechnik GmbH
> >Ralf Joachim
> >Raiffeisenstra�e 11
> >D-72127 Kusterdingen
> >Germany
> >
> >Tel. +49 7071 3690 52
> >Mobil: +49 173 9630135
> >Fax +49 7071 3690 98
> >
> >Email: [EMAIL PROTECTED]
> >Web: www.syscon-world.de
> >
> >
> >
> >-----------------------------------------------------------
> >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
