tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Johnson <>
Subject Re: Singleton across multiple contexts
Date Sun, 15 Jun 2003 19:22:57 GMT
On Sun, 2003-06-15 at 10:51, Antonio Fiol BonnĂ­n wrote:
> What I dislike is having to go out of the app to do app-internal calls. 
> RMI, socket, CORBA, HTTP, ... I don't mind: I just dislike the idea.

With good reason. :-)

> I do have a database. Databases are supposed to store data, aren't they? ;-)

Application or workflow state is data, isn't it?

> Now seriously... My application includes a web interface to a "kind of" 
> workflow system.
> This component is the "workflow engine", which is in charge for 
> automatic (background) state changes and actions. When my 
> business/persistence logic changes a state, new potential tasks for this 
> "engine" arise. So it has to be notified (=called) from any context that 
> may change a state.

The Tomcat user's list isn't the best place to discuss the design of
your application, but it seems there's no good way to use a singleton
across webapps. (Not that I searched the archives...)

Also, I guess you are relying on method synchronization/instantiation to
ensure that work gets done just once. That's one way of locking logic
(the easiest) but -- as you know -- it falls apart when you use multiple
classloaders. But there are other ways of locking, external file locks
or maybe database bits you can use to keep tack of state and future

The only other thing I can suggest is to consider your options carefully
before continuing. I don't have a clear understanding of what you've
already designed, but I'd avoid doing something hackish like sockets
inside Tomcat at pretty much any cost. If it can't be avoided, then I
guess you write it and debug the snot out of it.

Heck, I'd probably choose poll a queue table every three seconds before
writing socket layers. :-)

Anyway, you seem to know what you're doing, so good luck to you.

Mike Johnson <>

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message