RE: Singleton across multiple contexts
I do have a database. Databases are supposed to store data, aren't they? ;-) Yeah, which is why ... 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. ... you should use one here. You are describing state changes that need to happen in an atomic manner and exist in one and only one place. The semantics of db interactions are perfectly suited for what you are trying to do. -- Jacob L E Blain Christen Entheal LLC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Singleton across multiple contexts
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, depending 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 socket. - Extract the component into another context, and connect to it via HTTP. --- 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 smime.p7s Description: S/MIME Cryptographic Signature
Re: Singleton across multiple contexts
Look in the archives and search for past Singleton discussions. http://marc.theaimsgroup.com/?l=tomcat-userw=2r=1s=singletonq=b http://marc.theaimsgroup.com/?l=tomcat-devw=2r=1s=singletonq=b Otherwise ... - EJB (???) - Use a custom JNDI Factory (see tomcat jndi docs) -Tim Antonio Fiol Bonnín wrote: 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, depending 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 socket. - Extract the component into another context, and connect to it via HTTP. --- 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]
Re: Singleton across multiple contexts
Hi Antonio, - Extract the component into a separate JVM, and connect to it via socket. 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. - Extract the component into another context, and connect to it via HTTP. 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... On Sun, 2003-06-15 at 08:21, Antonio Fiol Bonnín wrote: 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, depending 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 socket. - Extract the component into another context, and connect to it via HTTP. --- 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 -- Mike Johnson [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Singleton across multiple contexts
- Extract the component into a separate JVM, and connect to it via socket. 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. - Extract the component into another context, and connect to it via HTTP. yuck. This isn't for locking or something is it? Nope. ;-) 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: 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, depending 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 socket. - Extract the component into another context, and connect to it via HTTP. --- 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 smime.p7s Description: S/MIME Cryptographic Signature
RE: Singleton across multiple contexts
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 - Extract the component into a separate JVM, and connect to it via socket. 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. - Extract the component into another context, and connect to it via HTTP. yuck. This isn't for locking or something is it? Nope. ;-) 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: 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, depending 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 socket. - Extract the component into another context, and connect to it via HTTP. --- 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]
Re: Singleton across multiple contexts
This is the best I could find: -- Each application is loaded with sepperate classloaders, so as long as the servlets are in the same application and the singleton is in it's classpath too it works. -- My singleton has to work *across* applications. Any ideas? Thank you very much. Antonio Fiol Tim Funk wrote: Look in the archives and search for past Singleton discussions. http://marc.theaimsgroup.com/?l=tomcat-userw=2r=1s=singletonq=b http://marc.theaimsgroup.com/?l=tomcat-devw=2r=1s=singletonq=b Otherwise ... - EJB (???) - Use a custom JNDI Factory (see tomcat jndi docs) -Tim Antonio Fiol Bonnín wrote: 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, depending 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 socket. - Extract the component into another context, and connect to it via HTTP. --- 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] smime.p7s Description: S/MIME Cryptographic Signature
Re: Singleton across multiple contexts
Antonio, remove your email digital certificate. Most of us can not answer your question since the reply forcing us to have a digital certificate as well. -Dan - Original Message - From: Filip Hanik [EMAIL PROTECTED] Newsgroups: Tomcat Sent: Sunday, June 15, 2003 10:59 AM Subject: RE: Singleton across multiple contexts 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 - Extract the component into a separate JVM, and connect to it via socket. 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. - Extract the component into another context, and connect to it via HTTP. yuck. This isn't for locking or something is it? Nope. ;-) 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: 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, depending 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 socket. - Extract the component into another context, and connect to it via HTTP. --- 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]
Re: Singleton across multiple contexts
This seems a good idea. Would it be possible to reload this class without trashing the whole Tomcat? 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 - Extract the component into a separate JVM, and connect to it via socket. 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. - Extract the component into another context, and connect to it via HTTP. yuck. This isn't for locking or something is it? Nope. ;-) 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: 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, depending 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 socket. - Extract the component into another context, and connect to it via HTTP. --- 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]
Re: Singleton across multiple contexts
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 actions. 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 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Singleton across multiple contexts
Place the jar (or class) in common/lib (or common/classes) and all will be ok. That is - until you need to make a change to your singleton class (or a class used by it) - in which case you will need to restart tomcat. (and not restart your webapp) -Tim Antonio Fiol Bonnín wrote: This is the best I could find: -- Each application is loaded with sepperate classloaders, so as long as the servlets are in the same application and the singleton is in it's classpath too it works. -- My singleton has to work *across* applications. Any ideas? Thank you very much. Antonio Fiol Tim Funk wrote: Look in the archives and search for past Singleton discussions. http://marc.theaimsgroup.com/?l=tomcat-userw=2r=1s=singletonq=b http://marc.theaimsgroup.com/?l=tomcat-devw=2r=1s=singletonq=b Otherwise ... - EJB (???) - Use a custom JNDI Factory (see tomcat jndi docs) -Tim Antonio Fiol Bonnín wrote: 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, depending 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 socket. - Extract the component into another context, and connect to it via HTTP. --- 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]
