• 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

cleanup on session expiring

 
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm not sure if this should be in this forum, the tomcat forum, or the distributed java forum. Sorry if I guess the wrong one (feel free to move it).

I'm attempting to broker all user access to the backend through a java user interface class User.java which contains an rmi connection to my database server. When a user logs in, User.java creates a connection to the database:


public User(String user, String pass) {
...
database = (Database)Naming.lookup("//" + ipDatabase + "/Database");
}



Upon successful login, the User class is stored to the jsp session:


User user = new User(username, password);
...
session.setAttribute("user", user);



When the session expires, will the connections to the database server be closed properly or do I need to add code to do this?

If so, I'd appreciate some advise. If a user goes to the logout page, I could call something like:


User user = (User)session.getValue("user");
user.close();
session.invalidate();



but that wouldn't clean up the sessions that time out.
 
Ranch Hand
Posts: 122
Mac IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I personally do not think its a good idea to keep the connection open in the User class. I'm not exactly sure obviously why you did this but I'd recommend not keeping it open. Unless you were trying to gain some type of performance you should just use a connection pool and when your done just return the connection back to the pool. Let the container handle that for you ... IMO
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Connections are expensive. Grab one when you need it, and close it when done. Connection pooling is a must for any kind of scalability.
 
Joel Sander
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the response. I don't think I was clear enough, my apologies.

The connection to the database happens in the server (named Database). The User class simply calls methods on the Database class via rmi. So, as far as I can tell connection pool happens (within Database) , so scalability is maintained assuming I coded this up properly.

My concern is with how garbage collection goes when a user's session times out. Is the interface to the server cleaned up properly?
 
Marshal
Posts: 28193
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
Presumably when the session expires, the part of the application server which keeps track of sessions will discard the session. And presumably it will be garbage collected.

My way of looking at these things is that the people who wrote the application servers were competent programmers, and that they wouldn't do something careless like keeping references to every session which had ever existed. So I have no evidence that they didn't do something stupid (which is why I said "presumably"), I just trust that they didn't.
 
Joel Sander
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Clapham wrote:Presumably when the session expires, the part of the application server which keeps track of sessions will discard the session. And presumably it will be garbage collected.

My way of looking at these things is that the people who wrote the application servers were competent programmers, and that they wouldn't do something careless like keeping references to every session which had ever existed. So I have no evidence that they didn't do something stupid (which is why I said "presumably"), I just trust that they didn't.



I'm sure they are more competent programmers than I am.

I just worry about things like rmi interfaces (or other items off the beaten path) being garbage collected. I've seen instances where java garbage collection didn't automatically happen (when tabs in java guis were closed), so I'm just trying to narrow down my possible memory leak issues.
 
Paul Clapham
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't see what the problem is, at least not from the web application point of view. If the expired session is the only thing with a reference to the User object, then when the session is eligible for GC then so is the User object. And if the User object is the only thing with a reference to the RMI connection, then the RMI connection is eligible for GC as well.

The only hitch would be if there were something else with a reference to that RMI connection. If you got that connection via JNDI from the application server then it would be the server's responsibility to deal with it, but otherwise its GC-ability doesn't seem to have anything to do with the app server.
 
Joel Sander
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That is encouraging: there is no JNDI used. Other User's will have their own rmi interface, but I assume that they won't interfere with each other's garbage collection.

Thank you!
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would not assume that the server implementation can "detect" that it has been disconnected properly. RMI connection should cleanup OK, but IF the RMI/Database interface provides a "close()" method, I would use it.

If you determine this to be an option, there is a simple way to do it. Just encapsulate your RMI connection in an object that implements the HttpSessionBindingListener, and implement valueUnbound(). When your session does a "timeout", this method will be called, and you can cleanly close the connection.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic