I cannot see the attachment, but a general beware re singletons.
Their usage differs from C++ in that a singleton class can be garbage
collected.
Typically this pattern is implemented with a static member of the class
holding an 'instance' of itself. If no other class references this instance
then it is a candidate for garbage collection ...
There is a command line switch on the jvm to stop collection of statics, but
be aware.
BTW: We happily use SSB as a remote interface to a Singleton and as yet have
had no problems
-----Original Message-----
From: Matthew Cooper [mailto:[EMAIL PROTECTED]]
Sent: 03 June 2001 23:58
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-user] will a stateless session bean instance be
existing thru out !!
Strictly speaking this violates the ejb spec (version 1.1 section 18.1.2)
due
to the limitation on static fields in order to ensure correct operation in
multiple-vm servers.
This may not matter to you but you should know that you are potentially
restricting the platforms your ejb's may run on.
For your info, I have attached an email I got in response to a query I made
to Sun re EJB singletons.
Matty
On Friday 01 June 2001 03:40, you wrote:
> Wrap the session bean in a java class that implements a singleton.
> Jeff
>
Email contents below:
Matty,
EJB was not designed as a facility for implementing in memory cache
managers.
With EJB 1.1, such a cache manager could be provided by a container as a
JDBC resource or as an in memory implementation of container managed
persistence.
With the forthcoming J2EE 1.4, the Connector facility could be used to
implement a cache manager.
Although the capability to write a singelton EJB looks like a simple
solution for your problem this functionality was specifically not
provided as part of the EJB architecture because it would introduce many
more problems than it would solve. Cache management is best handled at
the 'systems' level of J2EE rather than at the component level.
The only problem with this approach is that J2EE vendors are not
currently required to provide in memory data managers so writing a
portable app that requires one is difficult.
-- Mark
[EMAIL PROTECTED] wrote:
>
> Name: Matthew Cooper
> Email: [EMAIL PROTECTED]
> Company: Cognoworks Inc
>
> Specification Comments:
> I have scoured the spec and the web for ways to implement what is
effectively a singleton in EJB's. The conclusion is that you cannot. This
seems to me to be a bit of a limitation as you can only implement state
across clients via a persistent entity EJB, which is not always required. A
memoroy only equivalent would be useful (see my example below).
>
> I have read some comments that a singleton would create a bottleneck and
so
limit scalability, but there are clearly some situations in which state
across clients is required, but state persisted in a database is not. (The
latter would be a much greater bottleneck of course). The extent of the
bottleneck could be decreased by careful design depending on the
application.
>
> Cannot the EJB spec provide for singletons (and so some centrally managed
state available across the EJB server or cluster).
>
> The alternatives suggested on the web include writing some remote service
that can be looked up using JNDI, but this makes development and deployment
more complex. Surely, in the same way the the message driven bean brings EJB
ease of use to JMS, a singleton-like solution can be provided.
>
> My example is...
>
> I need to implement a license server for EJB sessions. This would ideally
hold current licenses in memory so that a server restart loses licence
allocation information and there would be no database access for licence
checking.
>
> Regards,
>
> Matty
>
> Matthew Cooper
> Chief Technical Architect
> Cognoworks Inc
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
