dan benanav wrote:
>
> An enterprise bean must not use thread synchronization primitives
> > to synchronize execution of multiple instances.
> >
> > [Same reason as above. Synchronization would not work if the EJB
> > Container distributed enterprise bean instances across several
> JVMs.]
>
> Does this imply that one should not use the synchronization keyword on any bean
> methods? At first one might think this seems clear from the above statement.
Yes.
> But note the remainder of the sentence, "to synchonize execution of multiple
> instances". I am not just nit picking here. There may be valid reasons to allow
> synchoronization primitives, for example even to use the synchronize keyword on a
> bean method.
Use of synchronization using synchronized() can lead to deadlock (see
someplace else in the archive).
> Note also the reason given. "Synchronization would not work if the EJB Container
> distributed enterprise bean instances across JVMs". One case I am thinking about
> relates to using a stateless session bean as a cache. (Yes I mean stateless,
> not stateful). In such a case I may want to use the synchronize keyword.
Which is exacly why you cannot use stateless as a cache. The cache
should be either an entity bean, or some resource manager (see Chris
Raber's response elsewhere in the archive).
There's a lot of login (and pain) into the caching mechanism. An EJB
server has more capabilities to interact between the different
components (e.g. more complex locking mechanism, notification of
distribution, diamond transactions, etc) that allow it to do a better
job.
> Suppose for example that you want to cache a database table using a stateless
> bean. When the bean instance is created (no relationship to calling the create
> method) it loads in the rows of the table into some structure, let's just say a
> vector. All updates, deletes or inserts to the table are stored in another table
> with a sequence number. Whenever a method is called the "Modify" table is read
> by the stateless bean and appropriate changes are made to the vector. I would
> need to make sure that updates to the vector are done in a synchonous way so I
> might use some synchronization primitives here. But note that I am only
> interested in this one bean instance. Each stateless bean would have it's own
> copy of the database table and I would only be interested in each stateless bean
> in isolation.
You cannot guarantee that. The EJB server may use at any point in time
any session bean it likes. Two method calls in the same transactions may
be directed to two different bean instances.
Entity beans give you an assurance against that with the proper
synchronization of ejbLoad/ejbStore, so you have some say in the matter.
> Note also that you may define a thread safe data structure(to be used in a bean)
> that itself use synchronization primitives and surely that would be OK?
No. The specification does not stop at "the class that implements
EnterpriseBean". It covers all classes used by the bean, regardless of
what interface they implement, excluding classes appearing in external
libraries (such as JDBC, JMS).
> So to summarize it would seem to me that using synchronization primitives is not
> strictly prohibited in ejb beans. It is only prohibited to use them to
> synchronized execution of multiple instances.
I believe that there is some restriction about using static fields and
that all static fields must be read only.
That's sufficient to not allow you to do anything useful with
synchronize().
Note, the Java security mechanism can prevent you from doing
Thread.start() anywhere in your bean (or related classes), but cannot
prevent you from doing synchronized().
Think twice before you do it. What works in the development environment
might fail big time (think deadlocks) in a production environment.
arkin
>
> dan
>
> ===========================================================================
> 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".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
