The only restrictions the 1.0 spec specifies are as follows:
Section 6.11.6 (p.44) under headings "The responsibility of the container
provider" and "Non-reentrant instances":
"The container must ensure that only one thread can be executing an instance
[of a bean implementation class] at any time. If a client request arrives
for an instance while the instance is executing another request, the
container must throw the java.rmi.RemoteException to the second request."
And section 16.4 (p. 117) under headings "Enterprise Bean provider
responsibilities" and "Programming restrictions":
* An enterprise bean is not allowed to start new threads or attempt to
terminate the running thread.
* An enterprise bean is not allowed to use thread synchronization
primitives.
I interpret this last point to certainly mean that the bean's business
method implementations (and also implementations of methods in the
SessionBean or EntityBean interface) may not declare synchronized. But what
if the bean implementation instance has a reference to, and invokes, a
shared resource in the VM in which it runs - a Logger class with a static
API, for example? Certainly the Logger's static methods need to be
synchronized to correctly sequence log output from multiple bean instances
in the same VM. But I've heard that some EJB containers scan jar files at
deployment time for the synchronized keyword and refuse to deploy if it is
found (regardless of whether it is found on a non- bean implementation
class) - which IMHO seems overly restrictive.
Unfortunately David's question is between these two extremes. A strict
interpretation of the last "programming restriction" point would probably
disallow what he wants to do, since it is within the code of the bean
implementation class. Pragmatically, I suspect it varies from container to
container whether such a bean would deploy and run correctly. But I also
wonder why an instance method of a bean implementation class would need to
be synchronized, given the spec restrictions.
Randy Stafford
Senior Architect
GemStone Professional Services
> -----Original Message-----
> From: Kirk Pepperdine [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, January 11, 2000 11:03 AM
> To: [EMAIL PROTECTED]
> Subject: Re: having a PRIVATE synchronized method in a session EJB
>
> I believe the restriction is against threading. Given this, there is
> no need to synchronize.
>
> Kirk
>
>
> -----Original Message-----
> From: David Olivares <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Date: Monday, January 10, 2000 7:52 AM
> Subject: having a PRIVATE synchronized method in a session EJB
>
>
> >hi there,
> >I need to have a PRIVATE synchronized method in a session EJB. I know the
> specs don't allow me to have a synchronized methods in EJBs, but I'm not
> sure if having a PRIVATE synchronized method is also forbidden. A way
> around this will be to have a helper class that does the synchronization
> for
> me, which I think is allowed in the specs.
> >thanks in advanced
> >David :)
> >
> >=========================================================================
> ==
> >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".
===========================================================================
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".
