Keeping objects in the session

We wish to put to the session many objects in groups. and are looking for a good way to do it. The point is that these objects are being built out of records we read from a DataBase and we wish to optimize the running time by reducing the querying.

The way we see it there are few options:

1. Use HashMaps or other data structure to hold them and put it entirly to the session. And then fetching an object will be something like:

X x;

Y y;

session.getAttribute("X_container").get(id_of_x);

session.getAttribute("Y_container").get(id_of_y);

2. put the objects one by one using a unique key. and fetching will be:

X x;

Y y;

session.getAttribute(X-id_of_x);

session.getAttribute(Y-id_of_y);

3. Better idea you got.

Which will be smarter?

thanks!

[840 byte] By [bobTheFunkySheepa] at [2007-10-2 17:00:08]
# 1

The first route is smarter as you will easily come into naming conflicts and confusing get calls where it becomes tough to tell exactly what you are getting with the second.

But a better route might be (if possible) to build Data Transfer Objects that represent 'row' data. It will be easier to manage what data goes where:

DTO dto = (DTO)session.getAttribute(id); <-- One id for all related information

Yy = dto.getY(); <-- Then get particular data you want from the DTO

Xx = dto.getX();In an easy to read manner...

But neither of the options may be practical. The more data you put in the session, the bigger it gets. The more users you have the more sessions you have. When you get a lot of users with big sessions you run out of memory on your server. Sessions don't scale so well (which is why we use databases). I am no DB expert, but perhaps optimizing your SQL, using stored procedures, well designed views, may help and be more scaleable than Sessions.

Just something to think about....

(ps, you might want to look up some design patterns for Enterprise applications. Some can help you optimize speed by reducing the size of any one given call to the DB and postponing getting data until it is needed. This way you may get more DB calls, but none are too long, and the app is more responsive to the user. For a good book on the subject look up Fowler's Patterns of Enterprise Application Architecture (http://www.martinfowler.com/books.html) )

stevejlukea at 2007-7-13 18:13:36 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...
# 2

Ahh - the eternal tradeoff between server memory, and database queries. Just be aware that this option could potentially chew up a lot of memory, and lower the maximum number of concurrent users on the system

Your first option sounds better to me. If you decide that you no longer need the "X_Container" data, you can get rid of it with one session attribute, rather than potentially multiple ones.

Also you could use a LinkedHashMap, in LRU mode, to keep the map to a manageable size (keeps track of which items have been most recently used, and you can remove the "eldest")

Question: is this common data accessible to all users, or should each user get their own individual "cache"? Could you store some/all of this data in application scope rather than session, and have multiple users share it?

Another potential option, is to look at the cachedRowSet (A java 1.5 feature) to see if that might help you out.

Good luck,

evnafets

evnafetsa at 2007-7-13 18:13:36 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...
# 3
Another alternative would be to use a third party cahcing package like ehcache or JCS. http://jakarta.apache.org/jcs/index.htmlThese offer features such as limiting the amount of memory used or storing the cache on disc.
tolmanka at 2007-7-13 18:13:36 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...
# 4

Thanks alot.

The answers really got us curious and we were wondering if you could give more information about few things:

The data is accessable in general to all users, 3-4 users basicly, not much more.

1. How can we create such "cache"?

2. How can we store something in the application?

3. We are using PreparedStatements and Connection Pooling. What else can be halpful?

appritiate it.

bobTheFunkySheepa at 2007-7-13 18:13:36 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...
# 5
The ServletContext can be used in the same fashion as the session, and is accessible in JSP as the application scope. All users have access to the same ServletContext object, so you need only one copy.
stevejlukea at 2007-7-13 18:13:36 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...
# 6

Сache library http://cache4j.sf.net allow create cache instance dynamically.

You can control cache behavior use many paremeters: ttl, object count, cache size, reference type.

You only need create cache instance in HttpSessionListener.sessionCreated(HttpSessionEvent se)

and remove then in HttpSessionListener.sessionDestroyed(HttpSessionEvent se).

yuzzza at 2007-7-13 18:13:36 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...
# 7
> 補che library http://cache4j.sf.net allow> create cache instance dynamically...Get lost, spammer.
warnerjaa at 2007-7-13 18:13:36 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...