Re: Accessing objects with any servlets, where the object is already pre-created
Anson, What about loading them up with an MBean and retrieving via the servlet? I've done this with JBoss/Tomcat, never with standalone tomcat though. Or, you populating the objects when the application starts and put the object it into the JNDI tree? John Moore On Tue, 2003-10-07 at 03:42, zeallousbigpond.net.au wrote: > Hi guys! > > Is it possible to create a bunch of objects, put them aside, and > Servlets can just access them any time without recreating those objects > or having to pass them around?? > > say, Vector s = a very large vector of Strings that will appear in many > servlets, but now I don't want to have to create them in each servlet, I > want to have them pre-created somewhere, and servlets will go grab them > when they need that Vector of Strings. > > Thanks! > > Anson > > > > - > 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: Accessing objects with any servlets, where the object is already pre-created
[of static methods and singletons] > Static methods are ok. But static data such as singletons cause many > questions in the list (a quick 30 second search turned these up): > I'm not saying there bad - in some cases they work great. But they can be > very confusing for others, which I why I try to avoid it. Static by itself is > tricky for some to comprehend. Oh, I see what you mean. Tomcat's use of multiple classloaders does present you with somewhat of a qualified notion of what a singleton is. If the class lives in CATALINA_BASE/shared, you get a `real' Singleton where one instance is used by all contexts; if you put the class in a context's WEB-INF, then you have a singleton that is only accessible to that context; if you put the class in the WEB-INFs of two different contexts, then you get two different instances of the Singleton class. Anyway, thanks for the discussion :) -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing objects with any servlets, where the object is already pre-created
Static methods are ok. But static data such as singletons cause many questions in the list (a quick 30 second search turned these up): http://marc.theaimsgroup.com/?l=tomcat-user&m=106002134305089&w=2 http://marc.theaimsgroup.com/?l=tomcat-user&m=105569056504526&w=2 http://marc.theaimsgroup.com/?l=tomcat-user&m=104576845201425&w=2 http://marc.theaimsgroup.com/?l=tomcat-user&m=10408531019&w=2 http://marc.theaimsgroup.com/?l=tomcat-user&m=104215937731998&w=2 http://marc.theaimsgroup.com/?l=tomcat-user&m=103082128121711&w=2 I'm not saying there bad - in some cases they work great. But they can be very confusing for others, which I why I try to avoid it. Static by itself is tricky for some to comprehend. static data duplicated because of duplicate classloaders just makes things painful to explain to my developers. -Tim [EMAIL PROTECTED] wrote: funkman> Static classes should be avoided as a general practice since funkman> they can may have classloading issues and painful side funkman> effects. See the archives for more detail. Static classes do funkman> work but they might have pitfalls depending on changing funkman> containers or deployment strategies. Could someone elaborate on this a little more? One of the earlier responses http://marc.theaimsgroup.com/?l=tomcat-user&m=106552445105027&w=2 Is pretty much a textbook implementation of the Singleton pattern. (Yes, I've seen static _initializers_ cause problems, but that's a completely different thing than a static method or a static member). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing objects with any servlets, where the object is already pre-created
funkman> Static classes should be avoided as a general practice since funkman> they can may have classloading issues and painful side funkman> effects. See the archives for more detail. Static classes do funkman> work but they might have pitfalls depending on changing funkman> containers or deployment strategies. Could someone elaborate on this a little more? One of the earlier responses http://marc.theaimsgroup.com/?l=tomcat-user&m=106552445105027&w=2 Is pretty much a textbook implementation of the Singleton pattern. (Yes, I've seen static _initializers_ cause problems, but that's a completely different thing than a static method or a static member). -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing objects with any servlets, where the object is already pre-created
Static classes should be avoided as a general practice since they can may have classloading issues and painful side effects. See the archives for more detail. Static classes do work but they might have pitfalls depending on changing containers or deployment strategies. -Tim Tom Lyle wrote: In fact, you can have one object in your servletContext which holds ALL of your data. I see how this approach works, but does it have any advantages over using one object that has static methods to access its data? For example I have a Config class that has a static initialisation block that reads data in from a properties file and then exposes the data with static methods, such as Config.getSomeValue() This does the job for me and means i can test my code in my IDE without deploying it to tomcat. Is there a good reason for not doing it this way? Just my after lunch thoughts. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Accessing objects with any servlets, where the object is already pre-created
> In fact, you can have one object in your servletContext which > holds ALL of your data. I see how this approach works, but does it have any advantages over using one object that has static methods to access its data? For example I have a Config class that has a static initialisation block that reads data in from a properties file and then exposes the data with static methods, such as Config.getSomeValue() This does the job for me and means i can test my code in my IDE without deploying it to tomcat. Is there a good reason for not doing it this way? Just my after lunch thoughts. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Accessing objects with any servlets, where the object is already pre-created
Hi there,
It will be a direct reference
thanks
Pete
-Original Message-
From: Vidar Langberget [mailto:[EMAIL PROTECTED]
Sent: 08 October 2003 14:00
To: Tomcat Users List
Subject: Re: Accessing objects with any servlets, where the object is
already pre-created
I understand that you can't put every object you want to cache in the
servletcontext, and a holder/wrapper object is needed. But you still need to
call servletContext.getAttribute() once for every request. The question is:
Does it matter performance-wise if the objects you store in the
servletContext are large or small. Ie, when you have the following code:
CacheManager cm = (CacheManager)servletContext.getAttribute("cache"):
FineObj fo = (FineObj)cm.getObject(key);
..
Is cm object getting a reference to the cache attribute(fast), or a copy of
the object stored there(slow)?
Sorry for not making my question clearer.
regards,
Vidar
- Original Message -
From: "Tim Funk" <[EMAIL PROTECTED]>
> The easy workaround is not store *many* objects into the servletContext
but
> to store a "holder object" into the servletContext.
>
> Rehashing is a non-issue if at initialization time all the information is
> loaded into the servletContext. If not future writes are done into the
> servlet context, then no rehashing is done.
>
> In fact, you can have one object in your servletContext which holds ALL of
> your data. Then you have full control of the hashing issues and don't need
to
> worry about excessive calls to (CAST)servletContext.getAttribute() or
worry
> about static variables.
>
-
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: Accessing objects with any servlets, where the object is already pre-created
I understand that you can't put every object you want to cache in the
servletcontext, and a holder/wrapper object is needed. But you still need to
call servletContext.getAttribute() once for every request. The question is:
Does it matter performance-wise if the objects you store in the
servletContext are large or small. Ie, when you have the following code:
CacheManager cm = (CacheManager)servletContext.getAttribute("cache"):
FineObj fo = (FineObj)cm.getObject(key);
..
Is cm object getting a reference to the cache attribute(fast), or a copy of
the object stored there(slow)?
Sorry for not making my question clearer.
regards,
Vidar
- Original Message -
From: "Tim Funk" <[EMAIL PROTECTED]>
> The easy workaround is not store *many* objects into the servletContext
but
> to store a "holder object" into the servletContext.
>
> Rehashing is a non-issue if at initialization time all the information is
> loaded into the servletContext. If not future writes are done into the
> servlet context, then no rehashing is done.
>
> In fact, you can have one object in your servletContext which holds ALL of
> your data. Then you have full control of the hashing issues and don't need
to
> worry about excessive calls to (CAST)servletContext.getAttribute() or
worry
> about static variables.
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing objects with any servlets, where the object is already pre-created
No. Via the Servlet Context javadocs ... "There is one context per "web application" per Java Virtual Machine. (A "web application" is a collection of servlets and content installed under a specific subset of the server's URL namespace such as /catalog and possibly installed via a .war file.)" -Tim Adam Hardy wrote: Another issue might be sharing the objects between servlets - I think that is what the original poster meant. Doesn't each servlet have its own servlet context? On 10/07/2003 01:50 PM Peter Guyatt wrote: Hi there, I beleive that using the setAttribute adds the object to a hashtable. If when the hashtable reaches a certian limit (usually 75% of its total size) it re-hashs which can be expensive and cause performance problems. The solution is to ensure that the limit is never reached. Is there a way to set the initial limit for the context? Pete -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: 07 October 2003 12:33 To: Tomcat Users List Subject: Re: Accessing objects with any servlets, where the object is already pre-created I can't see why there would be a difference. -Tim Vidar Langberget wrote: Have you noticed any performance problems with storing large amounts of data in the servlet context? I'm developing a cache for my webapp, and I can't decide if I want to use a static class or store cache instances in the servlet context. Vidar - Original Message - From: "Tim Funk" <[EMAIL PROTECTED]> My preference is to store the data into the servlet context (using setAttribute). Then no static variables are needed. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing objects with any servlets, where the object is already pre-created
The easy workaround is not store *many* objects into the servletContext but to store a "holder object" into the servletContext. Rehashing is a non-issue if at initialization time all the information is loaded into the servletContext. If not future writes are done into the servlet context, then no rehashing is done. In fact, you can have one object in your servletContext which holds ALL of your data. Then you have full control of the hashing issues and don't need to worry about excessive calls to (CAST)servletContext.getAttribute() or worry about static variables. -Tim Peter Guyatt wrote: Hi there, I beleive that using the setAttribute adds the object to a hashtable. If when the hashtable reaches a certian limit (usually 75% of its total size) it re-hashs which can be expensive and cause performance problems. The solution is to ensure that the limit is never reached. Is there a way to set the initial limit for the context? Pete -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: 07 October 2003 12:33 To: Tomcat Users List Subject: Re: Accessing objects with any servlets, where the object is already pre-created I can't see why there would be a difference. -Tim Vidar Langberget wrote: Have you noticed any performance problems with storing large amounts of data in the servlet context? I'm developing a cache for my webapp, and I can't decide if I want to use a static class or store cache instances in the servlet context. Vidar - Original Message - From: "Tim Funk" <[EMAIL PROTECTED]> My preference is to store the data into the servlet context (using setAttribute). Then no static variables are needed. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing objects with any servlets, where the object is already pre-created
Another issue might be sharing the objects between servlets - I think that is what the original poster meant. Doesn't each servlet have its own servlet context? On 10/07/2003 01:50 PM Peter Guyatt wrote: Hi there, I beleive that using the setAttribute adds the object to a hashtable. If when the hashtable reaches a certian limit (usually 75% of its total size) it re-hashs which can be expensive and cause performance problems. The solution is to ensure that the limit is never reached. Is there a way to set the initial limit for the context? Pete -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: 07 October 2003 12:33 To: Tomcat Users List Subject: Re: Accessing objects with any servlets, where the object is already pre-created I can't see why there would be a difference. -Tim Vidar Langberget wrote: Have you noticed any performance problems with storing large amounts of data in the servlet context? I'm developing a cache for my webapp, and I can't decide if I want to use a static class or store cache instances in the servlet context. Vidar - Original Message - From: "Tim Funk" <[EMAIL PROTECTED]> My preference is to store the data into the servlet context (using setAttribute). Then no static variables are needed. - 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] -- struts 1.1 + tomcat 5.0.12 + java 1.4.2 Linux 2.4.20 RH9 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Accessing objects with any servlets, where the object is already pre-created
Hi there, I beleive that using the setAttribute adds the object to a hashtable. If when the hashtable reaches a certian limit (usually 75% of its total size) it re-hashs which can be expensive and cause performance problems. The solution is to ensure that the limit is never reached. Is there a way to set the initial limit for the context? Pete -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: 07 October 2003 12:33 To: Tomcat Users List Subject: Re: Accessing objects with any servlets, where the object is already pre-created I can't see why there would be a difference. -Tim Vidar Langberget wrote: > Have you noticed any performance problems with storing large amounts of data > in the servlet context? > > I'm developing a cache for my webapp, and I can't decide if I want to use a > static class or store cache instances in the servlet context. > > > Vidar > > - Original Message - > From: "Tim Funk" <[EMAIL PROTECTED]> > > >>My preference is to store the data into the servlet context (using >>setAttribute). Then no static variables are needed. > - 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: Accessing objects with any servlets, where the object is already pre-created
I can't see why there would be a difference. -Tim Vidar Langberget wrote: Have you noticed any performance problems with storing large amounts of data in the servlet context? I'm developing a cache for my webapp, and I can't decide if I want to use a static class or store cache instances in the servlet context. Vidar - Original Message - From: "Tim Funk" <[EMAIL PROTECTED]> My preference is to store the data into the servlet context (using setAttribute). Then no static variables are needed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing objects with any servlets, where the object is already pre-created
Have you noticed any performance problems with storing large amounts of data in the servlet context? I'm developing a cache for my webapp, and I can't decide if I want to use a static class or store cache instances in the servlet context. Vidar - Original Message - From: "Tim Funk" <[EMAIL PROTECTED]> > My preference is to store the data into the servlet context (using > setAttribute). Then no static variables are needed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing objects with any servlets, where the object is already pre-created
My preference is to store the data into the servlet context (using setAttribute). Then no static variables are needed. -Tim Peter Guyatt wrote: Hi there, Use somthing like this private static stringHolder instance; -Original Message- From: zeallousbigpond.net.au [mailto:[EMAIL PROTECTED] Sent: 07 October 2003 11:43 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Accessing objects with any servlets, where the object is already pre-created Hi guys! Is it possible to create a bunch of objects, put them aside, and Servlets can just access them any time without recreating those objects or having to pass them around?? say, Vector s = a very large vector of Strings that will appear in many servlets, but now I don't want to have to create them in each servlet, I want to have them pre-created somewhere, and servlets will go grab them when they need that Vector of Strings. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Accessing objects with any servlets, where the object is already pre-created
Hi there,
Use somthing like this
public calss stringHolder {
private static stringHolder instance;
private Vector v;
public static stringHolder Instance() {
if (instance == null) {
instance = new stringHolder();
}
return instance;
}
private stringHolder() {
v = new Vector();
}
public addString (String s) {
v.add(s);
}
public Vector getStrings() {
return v;
}
}
There now all you have to do is call the Instance() method to get a handle
on the class.
There will only ever be one instance so it can be used between multiple
Servlets
Hope this helps
Thanks
Pete
-Original Message-
From: zeallousbigpond.net.au [mailto:[EMAIL PROTECTED]
Sent: 07 October 2003 11:43
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Accessing objects with any servlets, where the object is
already pre-created
Hi guys!
Is it possible to create a bunch of objects, put them aside, and Servlets
can just access them any time without recreating those objects or having to
pass them around??
say, Vector s = a very large vector of Strings that will appear in many
servlets, but now I don't want to have to create them in each servlet, I
want to have them pre-created somewhere, and servlets will go grab them when
they need that Vector of Strings.
Thanks!
Anson
-
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]
