It seems the original intent of this query (and the one in the thread on
"Static variables in EJB") is to implement a singleton-type of bean. Given
that session beans are not sharable, EJBs in general don't support mutable
statics, and implementing it as an entity bean seems somewhat kludgy (in
that there may be no persistent state or primary key), should this singleton
not even be an EJBean?
It's actually a question I'm trying to answer for a particular problem,
where our singleton may preload some data and perform
computationally-intensive analysis, and simply have the post-analyzed
results available for N session beans/clients (without desiring to have the
results persisted).
Should something like this simply be a Java singleton class, but not an
EJBean? In this case, there would be one instance per executing VM
environment, which would be OK.
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Tom Valesky
> Sent: Thursday, April 15, 1999 9:37 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Shared EJBs
>
>
> Well, session EJBs are inherently limited to one client. If
> you want to have a bean
> that's concurrently accessed by several clients, you'll need
> to make it an entity bean.
> If it's an entity bean, it'll have to have _some_ persistence
> mechanism underneath it
> (because the container doesn't necessarily keep a running
> instance for every entity
> bean -- more typically, it'll have a pool of identityless
> instances and load the state
> information into them as necessary. I was originally going to
> suggest that you use
> an entity bean with bean-managed persistence but don't bother
> to implement the persistence mechanism, but you _will_ need
> to implement it because of the pooling thing.).
>
> ==============================================================
> =============
> Tom Valesky -- [EMAIL PROTECTED]
> http://www.patriot.net/users/tvalesky
>
> -----Original Message-----
> From: J. Jawahar <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Date: Wednesday, April 14, 1999 2:40 PM
> Subject: Shared EJBs
>
>
> >We need to write objects that contain transient (non-presistent) data
that
> >needs to be shared among multiple clients. My understanding
> of stateful
> >session EJBs is that they are meant to be instantiated and
> used by a single
> >client. What kind of EJBs should we use to implement a
> shared object -- for
> >instance an EJB that implements shared cache of some kind?
> >
> >Please note that this requires that multiple clients be able to
> concurrently
> >access the object with the object itself providing the necessary
> >synchronization. It appears that session EJBs don't allow
> concurrent access
> >(they throw a remote exception).
> >
> >I also am told that EJBs are not allowed to do custom
> synchronization
> (e.g.
> >don't make any wait() or notify() calls). Is this true?
> Isn't this overly restrictive?
> >
===========================================================================
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".
