dan benanav wrote:
>
> 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.
There's a difference there. A good concurrency engine will use a locking
mechanism with deadlock detection, so it will detect and report the
deadlock.
Synchronized() does not support any deadlock detection, it will simply
hang up your two threads for eternity.
A good EJB container should perform synchronization with dead lock
detection even when running a transaction across several JVMs (see
elsewhere in the archive).
synchronized() can't do that.
> 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.
Nothing really. You're right.
arkin
>
> 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
--
----------------------------------------------------------------------
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".
