Hi Vinay, hi all,
Vinay:
>>> This basically means that even within the same transaction the
>>> rowid will be updated if the client attempts to do an update
>>> [or delete].
>>> Do we now need to check for rowid being null and falling back
>>> to the primary key if it is not? I had written some code for
>>> this and was surprised that it was never being called.
Georg:
>> Which commit option was set for your entity bean? If it were B
>> or C, it's clear, that the instance is loaded within a TX, but
>> with A and with B (outside TX) the load should NOT happen, thus
>> the check for a null rowidValue would be better.
Vinay:
> Nope! That is what I thought as well. The bean *is* being loaded
> even with commit options A and B, for the same operation with the
> transactions settings remaining the same.
If you are right, I would consider it a bug, rendering commit
option A and B useless, which promise bean caching. And I checked
against binary JBoss 2.2.1, BMP, commit option A and Requires:
DEFINITELY the sequence of calls when creating an Entity bean is
TX 1
| - setEntityContext()
| - ejbCreate()
| - ejbPostCreate()
TX 2
| - <getter method>
| - <setter method>
| - ejbStore()
As you see, there is NO ejbLoad() between ejbPostCreate() and
the business methods, in fact ejbLoad() on this bean is NEVER
called, except after passivation/reactivation, as expected.
This same behaviour should be seen also with CMP!
If this behaviour has changed with the current CVS JBoss there
must be some problem been introduced.
regards
Georg
___ ___
| + | |__ Georg Rehfeld Woltmanstr. 12 20097 Hamburg
|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10
PS: Sorry, I just can't test with the CVS version.
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
