Chip Wilson wrote:
>"Willecke, Dirk" wrote:
>> A similar problem occurs if an entity bean is updated by some business
>> method and a finder method is invocated in the same transaction.
>> For example: You have a person (entity bean) with pk = 100 (personNumber)
>> and name = "Simpson". You do a person.setName("Smith"). In the same
>> transaction there is an invocation of findByName("Smith"). Will our
>> person with pk = 100 be in the result?
>
>No, it will not be in the result. ejbStore methods are called when the
>transaction is committed. The SQL is not executed until ejbStore is
called,
>therefore the update statement has not been exectuted if the transaction
has not
>been committed. If the update statement has not been executed, then the
select
>statement will not see the change, even though it is executed from within
the
>same database transaction.
>
>> I think this is not specified.
>
>It is specified by nature of specifying when ejbStore is called.
See below!
>
>>
>> I can't find something in the spec about it. If a container simply
executes
>> the finder method, this would look up the database and person No 100
>> wouldn't
>> be found. By the way: a findByName("Simpson") would find Mr. Smith!!!
>
>It would find Pk=100. If the finder method is called from within the same
>transaction, then when the finder method on the home interface returned the
>remote object, it would reference the same entity bean instance in memory,
where
>the name has already been changed. Therefore a call to getName would
return the
>correct result for the transaction context, "Simpson". If the finder
method is
>called from outside the transaction, then the container must implement the
I in
>ACID (Isolation) in a defined way. These are clearly specified in the
spec.>>
The finder method findByName("Simpson") would look up the database and find
person No 100, because the instance's state hasn't been synchronized. A call
to
getName would of course return the correct, actual value "Smith" (The name
was
changed from "Simpson" to "Smith" not vice versa). But does it sound okay
for
a client to do a findByName("Simpson"), iterate the result set and then find
some objects in the result set with obj.getName() <> "Simpson" ?
>>
>> But coincidentally the container could have passivated the bean.
>
>An entity bean involved in a running transaction cannot be passivated.
I think you're wrong. The specification says:
"The container can choose to passivate an entity bean instance within a
transaction. To passivate an instance, the container first invokes the
ejbStore method to allow the instance to synchronize the database state
with the instance's state, and then the ejbPassivate method to return
the instance to the pooled state." (Chapter 9, Entity Bean Component
Contract)
I think all problems I mentioned still exists. And I think the only way
to avoid them is to let the container synchronize all entity beans which
are envolved in the current transaction.
Dirk.
Dirk Willecke, Datenzentrale Schleswig-Holstein
Tel. ++49 431 3295-860 / Fax ++49 431 3295-510
http://www.landsh.de/dzsh/
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
