see below
"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.
>
> 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.
>
> But coincidentally the container could have passivated the bean.
An entity bean involved in a running transaction cannot be passivated.
> In this
> case
> there would have been done an ejbStore() and the findByName("Smith") would
> correctly find person No 100. The result of the find method is dependent of
> a possible passivation has occured or not!
It doesn't work this way.
>
> Shouldn't the container synchronize the state of all entity beans involved
> in the current transaction before executing a finder method to avoid these
> problems?
I would argue that the "problems" here are in the design of the application, not
in the EJB spec.
begin:vcard
n:Wilson;Chip
tel;fax:(214) 358-0353
tel;work:(214) 642-4559
x-mozilla-html:TRUE
url:http://www.axyssolutions.com/
org:Axys Solutions
adr:;;;Dallas;TX;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Application Architect
note:Sun Certified Java Architect
x-mozilla-cpt:;-25088
fn:Chip Wilson
end:vcard
