It is hard for me to believe that synchronize is not allowed (even as wrappers around
code within method calls). For example suppose that I have created a multi-safe data
structure using synchronize. Are you saying that I cant use that data structure
within the bean? Surely some of the jdk datastructures have synchronized methods.
Now if that is allowed I could achieve the same affect by using non-synchronized
methods and wrapping it around a synchronized block within a bean method call.
By the way pessimisitic concurrency can also lead to deadlock. Any time things are
synchronized deadlock can occur so the programmer has to be careful. So a deadlock
argument is not necessarily proof that synchronize should not be used.
Also you missed my point about caching in the stateless bean. I may not necessarily
care that multiple bean instances exist or that they don't have the same data at all
times or that different method calls may be handled by different instances. Take an
extreme case where no updates are occurring. Each stateless bean after creation would
contain a copy of the database table. So they would all contain multiple copies of the
same data. What is wrong with that? As long as I can control the maximum number of
stateless beans I may not care.
dan
Assaf Arkin wrote:
> 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".
