Comments on: EJB 3.1: Immediate feedback on EJB Singletons and concurrency needed

By: JR

JR — Tue, 20 Jan 2009 22:03:53 +0000

So what transpired of this? Is this in the 3.1 release, and can you brief the behavior of the singleton in the clustered environment. Does the implementation allow only one cluster-wide instance with data shared in Jboss cache?? Thanks

By: Richard

Richard — Wed, 07 May 2008 22:16:09 +0000

I realize that its a bit late (to say the least), but…

Please let there be an easy way to create a cluster-wide singleton with an annotation! In fact, I’d love to see the cluster mindset change a little bit. Let’s face it, few people are using EJB to create simple throwaway apps that will never run clustered. Many of them may not grow to that point, but anyone intentionally writing a low-use app is unlikely to use an environment such as EJB in which to do it.

Having an easy way to create a cluster-wide singleton without having to worry about cache access issues, the risk of creating two objects and destroying one if there’s a cache race (generally not a big deal, but something you have to deal with anyway), etc, would be wonderful. Sure, it can be done without it, but one of the massive wins in EJB3 has been taking concepts that were difficult and handling them with a single annotation so the developer doesn’t have to risk the “enter everything correctly and get your desired behavior; miss one thing and encounter weirdness” behavior we all grew to hate with EJB2…

By: Alex

Alex — Thu, 24 Jan 2008 15:11:04 +0000

Three different concerns here:

1- Activation timing
2- Concurrency
3- Instance count

I wouldn’t use a term such as Singleton to cover the three.

By: Odi

Odi — Mon, 01 Oct 2007 16:21:43 +0000

@Steven: Unlike Servlets a SLSB doesn’t need to be reentrant, and I quite like that. They are stateless in the sense that the caller must not rely on state being preserved between method calls as consecutive calls may go to different instances. You can still use instance variables in a SLSB (for example to hold state during private method calls without passing it through method parameters) and it’s still thread-safe.

By: KRo

KRo — Thu, 27 Sep 2007 05:19:22 +0000

-1 Singleton sb.

I prefer a facade slsb delegating through to a pojo singleton with the facade slsb statically referencing the singleton. The pojo singleton uses synchronize (the java language rather than introducing an alias annotation to the EJB) as necessary. When newer and better K EE 10 comes along, I can easily replace facade EJBs with whatever the K server requires. Or, I can re-use the pojo singleton in both J EE 5 and ESB in the same architecture.

But, I’m still wondering why I find the Timer EJB so useful (it is a singleton?) – or was the Timer EJB simply misnamed and forced into an EJB construct when it might better have been a service bean?

By: Andy

Andy — Thu, 27 Sep 2007 01:40:15 +0000

+1 SLSB instance pools blow.

By: Tim Shaw

Tim Shaw — Wed, 26 Sep 2007 09:46:05 +0000

I think there are 2 aspects to this – initialisation (a la ‘startup’ servlet approach) and shared state maintenance (a la ‘stuff it in the DB’).
I would vote for both – they are entirely different use cases.
@Startup – run once and forget : single ‘onStartup’ method called at a specific point in the container lifecycle
@Service – singleton with maintained state as per the JBoss one : I certainly vote for a single ‘view’ of a Service bean across a cluster … but in that case it’s the state that’s important – there could be many instances of the class itself. My use case here would be a simple cache – but I also see a need for shared state across many MDB’s running in parallel. Note that a service bean could be instantiated after startup – and thus have available the other beans it might need.

By: Heiko W. Rupp

Heiko W. Rupp — Mon, 24 Sep 2007 15:48:44 +0000

I think it is a good idea to have a @Singleton ( I don’t mind the name of it)
But please make concurrency semantics very explict. Don’t leave that to the container implementor.
I guess explicitly specifying it via annotation with the sensible default of single threaded (as principle of least surprise) is best.

And yes allow those singletons to be started before other “regular” EJBS so that they really can be used to ‘bootstrap’ the enterprise part. I don’t like the @PostConstruct annotation here, as it has a different semantic.

Also make it very clear if such a service can access other EJBs when it is initially called (do we need two initialization phases?)

By: billburke

billburke — Mon, 24 Sep 2007 14:23:26 +0000

The singleton may not be a service. It may just be an “initialization” object that, for example, pre-populates JPA’s global cache, or provides a bridge for a framework developer. There’s still debate in the eg on whether singeltons should be allowed to be initialization objects (and have a different component for this like servlet listers), but that will be a topic for another blog.

By: Laird Nelson

Laird Nelson — Mon, 24 Sep 2007 14:07:24 +0000

Hey, I like the last comment (Elias). Agreed, upon further thought, that it isn’t really the Singleton nature that’s at issue here, it’s more the…the…SharedResource-ness? Elias, I’m not so sure it’s really a Service, per se; maybe there’s a better word.