I don't think so... At least, I cannot imagine how it would be done.
I have just come across another possibility:
Store the singleton instance in the system properties.
What do you think of this? Is it calling for trouble?
Antonio Fiol (This time w/o certificate)
Filip Hanik wrote:
I have not followed this thread, but putting the class in common/lib or shared/lib should make it a singleton across contexts
Filip
-----Original Message----- From: Antonio Fiol Bonn�n [mailto:[EMAIL PROTECTED] Sent: Sunday, June 15, 2003 10:52 AM To: Tomcat Users List Subject: Re: Singleton across multiple contexts
via socket.
- Extract the component into a separate JVM, and connect to it
This is what I'd do, but I'd also write a client class to get access. I suppose you could use RMI or something, but I'm not familiar with that. Whatever you're comfortable with, I guess.
You could also spin off this class in it's own thread inside one of your classloaders. That way it would shutdown and start up with the server (or maybe that's a drawback...) and you wouldn't have to add the overhead of another VM.
In fact, it *is* a thread. It starts and stops with the server. Everything was really beautiful until I had to split my app in four contexts.
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.
via HTTP.- Extract the component into another context, and connect to it
Nope. ;-)yuck.
This isn't for locking or something is it?
I get the feeling you're trying to use a class for storing or accessing something the way most people use a database...
I do have a database. Databases are supposed to store data, aren't they? ;-)
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.
On Sun, 2003-06-15 at 08:21, Antonio Fiol Bonn�n wrote:depending
Hello,
This question is probably not specific to Tomcat, but a Tomcat-specific answer could well suit my needs.
I have an application which I have split in several different contexts.
I have done so, to allow different kinds of access to the app,
via socket.on the web server the requests are coming from.
However, I need a common unique component that "ties" all the contexts together.
There must be a *single* instance of this component, otherwise inconsistencies or duplicate work might arise. OTOH, it must be accessible from all the contexts.
Calls to this component are very simple (calls to void methods) but moderately frequent.
I have thought of several possibilities:
- Extract the component into a separate JVM, and connect to it
via HTTP.- Extract the component into another context, and connect to it
--- I like none of those.
- Create the instance from the first context needing it, and making it available to all of them. --- I like this best, but I have no idea of how to do that.
Yours sincerely,
Antonio Fiol
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
