wood burning stoves 2.0*
The moose likes Struts and the fly likes Struts 2 session writing efficiency / timing Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Frameworks » Struts
Bookmark "Struts 2 session writing efficiency / timing" Watch "Struts 2 session writing efficiency / timing" New topic
Author

Struts 2 session writing efficiency / timing

Sandy Noble
Greenhorn

Joined: Apr 30, 2009
Posts: 13
Hello everyone, can a struts expert help clear up the vagueness I have about how struts 2 runs sessions? I have a large application that has action classes using sessionaware and the servletconfig interceptor is running, and it all works fine, but it does a few things more than once (belt and braces). I'm trying to optimise it a bit, to snip out some code that just duplicates activity that struts does anyway.

My understanding of the process is:
1. servletConfig (inteceptor on the way in) gets the http session from the server request and calls setSession() to put it into my action class. This creates a local version of the map that my class can use during the lifetime of the action.
2. I explicitly put some stuff into that map (in the action), and take some stuff out while doing my execute().
3. servletConfig (on the way out) puts the contents of the map into the http session.

So manipulation of the map in the action class itself has no real I/O cost, because it doesn't get fired back to the server until the action is finished. So I don't need to be worried about multiple .put()s creating lots of session traffic.

Am I right? Because I thought I had read somewhere (online) that the http session is explictly updated every time any value is put() into the map in the action class, but now I can't find that article again, and it seems a bit wasteful to be true.

To put it in context, this app historically had huge objects in the session (1MB+), and our session storage server keeps logs of all data going in or out for transactional safety, and those transactional logs were out of control (hundreds of GB a day), and there were strong suspicions that struts' way of handling sessions was making this worse than it might otherwise be, since each put() required the session map getting afresh. The size of the session objects is much (MUCH) smaller now, so it's a bit of a moot point, but I'd prefer to know exactly whats going on.

Thanks!
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

The "servletConfig" interceptor doesn't do anything "on the way out". I'm not sure what you're talking about when you say that every "put" requires a "session refresh". This is the entirety of the servlet config interceptor:
Sandy Noble
Greenhorn

Joined: Apr 30, 2009
Posts: 13
Thanks for your message David, the code for ServletConfigInterceptor is much smaller than I imagined.

David Newton wrote:I'm not sure what you're talking about when you say that every "put" requires a "session refresh".


Well, exactly that though I didn't use the phrase "session refresh". If I am in my action, and I do getSession().put(blah, blah) ten times, does that hit the http session server ten times? It looks to me like it must do, since there is nothing in the interceptor that will roll up all my modifications to the session map and send them back to the http session server in one go. Unless this happens at a deeper level in the ActionContext.

Can anyone clarify? And if it _does_ do a http hit every time a value is updated, is there a way to roll them up? Actually I suppose I could just use a local HashMap for my updates and then do a getSession().putAll(localMap). Any downside to that? Am I reinventing the wheel?

Thanks!
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

each put() required the session map getting afresh.

What "session server" are you talking about? Are you talking about session replication in a clustered environment?
Sandy Noble
Greenhorn

Joined: Apr 30, 2009
Posts: 13
Hello, yes there's a cluster of application servers (Borland Enterprise Server) that all use a centralised session storage server in preference to their local stores. The centralised server is on a different physical machine so there is quite an overhead in session access.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

There's nothing Struts-specific to tell you then--session attributes are the same regardless of the underlying framework.

When and how the session is updated/replicated would be server-specific. To me, it wouldn't make any sense for session data to be replicated *during* a request, since each single request would (I assume) be handled by a single server. Replicating a session during a request would be pointless since other servers would be guaranteed to not need updated session data until the next request. But I could be totally wrong about that, and my understanding of a lot of replication details is rather limited :)

I don't understand how logging the data itself does anything for transactional safety, though; it's just a log file.
Sandy Noble
Greenhorn

Joined: Apr 30, 2009
Posts: 13
Thanks for your help David, it's much appreciated. I think I am just fairly unclear about how struts fits into the whole http request/response cycle, and sometimes think it is being a bit more magic than it really is. You have shed some light on it.

sn
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Well, we can address the fuzzy bits--which parts of the Struts 2 stuff are giving you issues?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Struts 2 session writing efficiency / timing