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
