I think there are 2 interesting issues worth exploring here -
1) Allowing an application to run custom code in a "container" vm, before the
vm begins processing - sort of like initialization
<Vendor>
GemStone lets you run initialization code via "VM Initializers". You can choose
to load the code (ala classes) from a specific deployed application or have it
be defaulted - which will use the System classloader. Obeying java classloading
rules all classloaders will first check if the class/code can be loaded from
its parent (ultimately System). This avoids having to worry about the custom
classloader details for each application for things like singletons or
inter-application code
</Vendor>
2) Managing Singleton objects across a server installation (which may include
multiple vm's)
Of course the EJB way would be to use an Entity bean.
As someone pointed out RMI seems quite useful - as a portable solution. I don't
know f that has too much appeal to it for EJB Component developers though.
<Vendor>
I think this is one classical case of using a shared cache where an object can
be bound (/stored) and accessed by concurrent users in memory. We call it PCA
for persistent shared cache
</Vendor>
-harsh-
GemStone Systems
Dave Wolf wrote:
> I believe Gemstone for one. The whole idea containers could use multiple
> VM's is one of the reasons that static members are illegal. The spec
> mentions this once or twice.
>
> Dave Wolf
> Internet Applications Division
> Sybase
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Luis Canals
> > Sent: Tuesday, September 26, 2000 12:56 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Using singleton from EJBs (not implementing singleton with
> > EJ B!)
> > Which EJB containers use multiple VM's?
> > From: Dave Wolf [mailto:[EMAIL PROTECTED]]
> > Sent: martes, 26 de septiembre de 2000 17:32
> > To: [EMAIL PROTECTED]
> > Subject: Re: Using singleton from EJBs (not implementing singleton with
> > EJB!)
> > > > A singleton pattern will not be very portable. Even if the
> > > static member
> > > > were portable which it is not, the use of custom ClassLoaders by most
> > > > containers will likely cause issues with your pattern.
> > > >
> > >
> > > It seems it would not be portable only if you want a singleton for all
> > > containers in cluster. But a singleton seems very portable and
> > applicable
> > > in situations where you want a singleton object per container and do not
> > > need to share that singleton between multiple containers.
> >
> > Not necesarilly. Its of course not a singleton across containers, but it
> > may not even be a singleton within the same container.
> >
> > 1) The container may use multiple VM's
> > 2) More common, the container may use a custom ClassLoader to load the
> > classes in order to support features like hot swapping. If so, the
> > singleton will only be unqique across a ClassLoader. Or, a more comman
> > issue would be as per the J2EE spec, each web app must have its own
> > ClassLoader. Meaning the singleton is only truly a singleton within the
> > single web application.
> >
> > Dave Wolf
> > Internet Applications Division
> > Sybase
===========================================================================
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".
