Question

I'm trying to figure out how to solve a design issue I've stepped into. Let's assume that in my application I need to have a kind of daemon/service that continuously works in the background managing a pool of objects in order to make them available to clients. In particular this daemon is in charge of managing the overall lifecycle of these objects.

Now, without diving in the details of this daemon scope, I was thinking how I can design this. My first idea was to rely on WorkManager API. Since I have a Singleton EJB modeling my application core the idea was to get a WorkManager and then spawn the daemon (obviously implementing Work). I've used WorkManager while developing a Resource Adapter and I thought I could use it also in an EJB, but standing Glassfish (3.1.2.2) support to WorkManager API (provided essentially by javax.resource.spi.work) I found that out of the RA context this is not possibile.

I gave a look at the web and found an interesting article by Daniel Veselka that seems to approach the problem introducing CommonJ implementation of WorkManager and I was definitively thinking about following this approach.

What do you think about this?

Was it helpful?

Solution

You can also use a timed bean that periodically reschedules itself, and sends JMS messages that represent actual pieces of work. It worked for us.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top