Hi Javier,
The question is about serializing access to session bean methods and not
about reentrancy. Anyway session bean does not have to be coded as
reentrant.
Refer section 7.5.6 of EJB2.0 PFD2, where the spec says while a SFSB is
serving a method request, other concurrent clients may get an Exception.
This is what you mentioned as in 10.14 of blue prints. But the EJB spec, in
the footnote, also mentions
"In certain special circumstances (e.g., to handle clustered web container
architectures), the container may instead queue or serialize such concurrent
requests. Clients, however, cannot rely on this behavior."
I guess many appserver vendors provide serialize access, as mentioned in the
Ed Roman books, which seems to be a cause of confusion.
Regards,
Hemant
www.pramati.com
----- Original Message -----
From: "JavierG" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 23, 2001 8:02 PM
Subject: reentrant beans
Hi:
In "Mastering Enterprise Java Beans" Roman states that, and I quote: "When
you call a method on a session bean instance, your EJB container guarantees
that no other clients are using that instance[...]Thus, if multiple clients
simultaneusly invoke methods on a session bean, they invocations are
serialized, or performed in lock-step..." but then, in the Java Blueprints
you can see things like this:
"Code Example 10.14 contains an excerpt from ShoppingClientController-
WebImpl. Notice that all the methods of ShoppingClientController are
synchronized
so that concurrent requests to ShoppingClientController are serialized.
This is done because an EJB container will throw an exception if a request
is made
to a session bean while it is servicing another request.
public class ShoppingClientControllerWebImpl
{
private com....ejb.ShoppingClientController sccEjb;
private HttpSession session;
public ShoppingClientControllerWebImpl(HttpSession session) {
this.session = session;
ModelManager mm =
(ModelManager)session.getAttribute("modelManager");
sccEjb = mm.getSCCEJB();
}
public synchronized AccountModel getAccount() {
CHAPTER 10 THE SAMPLE APPLICATION 288
return sccEjb.getAccount().getDetails();
}
...
public synchronized Collection handleEvent(EStoreEvent ese) {
return sccEjb.handleEvent(ese);
}
public synchronized void remove() {
sccEjb.remove();
}
}
Code Example 10.14 ShoppingClientControllerWebImpl"
I'm I missing something? According to Roman the EJB container *guarantees*
thread safe access to the bean instances...
Sorry if this a silly question, but I do see a contradiction here.
Sincerelly
J.
===========================================================================
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".
===========================================================================
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".
