• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Where are my sessions stored?

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,
I'm new to j2ee and tomcat, but I'm starting on an existing application. Can anyone tell me where the server stores the session files by default? Where is this configured? Also, are there any common locations to store session information?

Thanks!
 
Ranch Hand
Posts: 820
IntelliJ IDE VI Editor Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think these docs explain it very clearly:

http://tomcat.apache.org/tomcat-5.5-doc/config/manager.html

 
Saloon Keeper
Posts: 27919
198
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Please note, however, that the aforementioned link is about the Tomcat persistent session manager, which is used to ensure that sessions can survive a server restart or cluster failover/load-balance operation.

HttpSessions are not actually require to ever exist in any sort of external storage. Thus, they may not actually have a "location" as such , and portable apps won't expect them to.

Creation and destruction of sessions themselves is part of the basic J2EE API function set, as is the entry, retrieval and removal of objects from the session's attribute dictionary. However, playing around with session external representations is something that should only be done if there's a compelling need. Not only do you run the usual risks of server and OS portability issues, you also can get clobbered if the internal session management architecture gets changed or if someone who doesn't know what you've done reconfigures the server.
 
Jon David
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Tim.

If I'm reading this correctly, it essentially means that Tomcat defaults to storing sessions in a non-persistent manner, and it does so using one single file that maintains all session data. Is that correct? If so, where is this file located?

Assuming that's correct, I further read it to mean that if I want to store persistent information either using file storage, db, I need to set that up in my tomcat conf folder, or specifically for an application in its META-INF folder. Regardless, I could put this information in a context.xml, web.xml, or server.xml. Is that correct?

Assuming that's correct, could someone give me an example of a *.xml configuration for either session file storage, or db storage? That would be a big help. Again, I'm new to j2ee. I'm used to setting a folder, and a template file name, and each session being stored separately.

Thanks again!
 
Marshal
Posts: 28271
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jon David wrote:If I'm reading this correctly, it essentially means that Tomcat defaults to storing sessions in a non-persistent manner, and it does so using one single file that maintains all session data. Is that correct? If so, where is this file located?



No, there's an assumption built into that statement. And that assumption is the word "file", which strongly implies that the session data is stored in what the operating system calls a file. Something on the hard drive, to put it less loosely. I don't believe that assumption is correct but referring back to the documentation might clarify.

Personally, I would expect that Tomcat stores session data as objects in the JVM -- in memory, if you like -- as that would be the simplest way to implement the spec. But I'm not a Tomcat expert and it could be more complicated than that.
 
Tim Holloway
Saloon Keeper
Posts: 27919
198
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It may never store sessions in a file at all. It's perfectly legal to simply build them in RAM and throw them away when the user logs/times out.

In fact, quite a few webapps depend on that behavior. People get sloppy and put non-serializable data in session objects. Tomcat isn't noted for warning people when they do that. As long as the session is in RAM, that's not a problem. But if the appserver decides to swap it out to a more durable medium, or to transmit the session to another server in the cluster, you've got a nonserializable data exception and/or lost data. And it can happen at unpredictable times.

It's one of the ways you can tell the "pro"grammers from the "amateur"grammers. Making sure that the app will work more than 99 times out of 100.
 
Sheriff
Posts: 67750
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:It's one of the ways you can tell the "pro"grammers from the "amateur"grammers.


Except for those times when it's done purposefully in order to prevent sensitive data from being serialized to disk.
 
Tim Holloway
Saloon Keeper
Posts: 27919
198
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Bear Bibeault wrote:

Tim Holloway wrote:It's one of the ways you can tell the "pro"grammers from the "amateur"grammers.


Except for those times when it's done purposefully in order to prevent sensitive data from being serialized to disk.



Or if it's some sort of weak reference where it's less trouble to reconstruct at need than to keep in persistent storage. References to ORM objects being a good example. But since the act of persistence - or lack thereof - isn't controllable or predictable, that sort of behaviour mechanism is definitely not for amateurs. You've got to explicitly provide for its recovery/reconstruction when and where it's needed and not just trust that it will be there.

Actually, I can make a good case for not keeping sensitive data in sessions at all. The closest thing to sensitive info that container-managed security allows an app to see is the user principal. The rest of the data (password, roles, etc.) never gets out of the container and into the app. You can test for a role, for example, but not query for a general enumeration, and the container never volunteers. In cases where a security server is involved, the direction of data flow is outwards only. All that comes back is a go/no-go indication.

Actual security services go one step further. Credentials are stored in byte arrays, not strings. That's because you can zap out the contents of a byte array once you're done with it, but strings linger in RAM until garbage collection has freed up the raw memory underneath them.
 
Jon David
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, this helps a lot, and not at all. I have a much better idea of how j2ee apps handle sessions now, but I realize that I have been asking the wrong question. I made a typical amateur error...i made an assumption about my problem, and asked a question about my assumption, as oppose to actually stating my problem.

The real problem is that my app loses its session after one page load. I login, and when I try to post, I get the following error:



I only get the error on my local machine, running OS X, but not on the dev machine running Linux. I assumed that the app was trying to write its sessions to somewhere that it didn't have permission to do so, but I no longer think that's the case.

To clarify, when I login the page reloads as though I am logged in, and it has the session. As soon as I navigate to any other page, it acts as if I am not logged in. I attempted to post on a page, and that generated the above error.

Any suggestions would be great. Thanks!

(Edit: I made the error message into 3 lines so it wouldn't force the post to be excessively wide - PC)
 
Tim Holloway
Saloon Keeper
Posts: 27919
198
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hmmm. Well, as best as I can read that, it looks like something's attempting to logout a session that was already logged out.

Got a stack trace to go with that message?
 
Jon David
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sure, here's then entire stack,



It seems like a sql error (which I don't *think* is the real problem, because it works elsewhere) but this line (and behavior mentioned earlier) makes me think it's a session issue,


Thanks again!
 
Tim Holloway
Saloon Keeper
Posts: 27919
198
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ummmm. Hibernate uses the term "session" to mean something entirely different and completely unrelated to a web session.

The critical message, however, is that it says that database table "app.postsubcategoryassn" doesn't exist in the database it's attempting to talk to. Nothing Tomcat-related to that at all.

If the table does exist, the jdbcs connection account that's attempting access may not have rights to it, since it's quite common for databases to deny something exists if you're not allowed to play with it.
 
reply
    Bookmark Topic Watch Topic
  • New Topic