> So in fact a bean *can* use third party classes that use synchronization
> primitives, even though the specification says it cannot.  I find this
> interesting.

No, the fact is that beans can use any class that uses synchronization,
because there's no way to enforce it.

But do not depend on synchronization to synchronize access to a shared
resource, since if you're not careful in understanding how an EJB
container might operate, it can work on one server and break on another.

>From what I can tell, Vector is pretty safe. The Java 1.2 collection
architecture is more extensible, so synchronization has been delegated
outside of the collection implementation.


> > If you use a Vector or Hashtable from one thread and something happens
> > to your thread inside the synchronized stuff, your Hashtable/Vector
> > might be corrupted. But you shouldn't care. IF something happens to your
> > thread, the EJB server will discard that bean (always).
>
> Is this not an argument for allowing users (knowing they run a risk) to
> create threads?  Granted and fully understood: a user may create a thread
> that could do some damage.  So what?

You are totally missing the point. You want to create a thread, go right
ahead and do it. Just be warned, the EJB container will not give you all
the services you expect, will not be able to manage your thread, might
terminate it without letting you know, will not restart it
automatically, etc.

Right now you're asking how do I create a new thread. But once you start
using threads you second question is going to be, why does it work that
way on EJB server A, and the other way on EJB server B? How do I use
connection pooling in threads? What happened to the security?

You need a more formal API to get into stage two. If you don't care
about these features or portability, just pick any EJB server that
allows you to start a thread (I believe most of them do), and use it.

But if you care about the container features in your threads, about
portability, about guaranteed behavior, try to stick to only well
documented APIs.

Just my recommendation.

arkin


>
> Cheers,
> Laird
>
> ===========================================================================
> 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".

Reply via email to