I have read different articles on Session Management and am aware of the different ways of implementing the same.
However below are few questions that I wanted to understand:
How session management is implemented in a real world application (e.g. cookies,url rewriting)?
What would be the steps and which is the best way to do the same?
What way should one prefer over another?
How is session management done wrt different data centers/clusters?
Thanks!
Its security risk to use cookies and url rewriting for sensitive data management. The best mechanism is to use http session in conjunction with https.
In real world scenarios, http session is used carefully to avoid bottle necks. simply rather than adding an entire object to session, an attribute which can be used to obtain an entity from database is carried over the session. bottom-line is that sessions need to be kept light weight.
session best practices include removing the session and invalidating it once its use is completed.
in EJB context, its always better to avoid Stateful session beans. If used, the bean has to be invalidated as the last invocation of the bean.
Related
I have a JSP-Servlet based Web application where I would like to achieve the following scenario.
I need to set the HTTP session alive time programmatically when I am creating the session.
I need to invalidate the session even though the user is actively using the application, which is why the classic Session Time out configurations in the deployment descriptor and session.setMaxInactiveInterval() will not work for me.
Thus, When I am creating the session, I need to make sure I provide the exact amount of time for which the session will be active.
Let me know how I can achieve this scenario. Thank you.
This page from the Hibernate tutorial on jboss.org says:
Hibernate offers three methods of current session tracking. The "thread" based method is not intended for production use; it is merely useful for prototyping and tutorials such as this one.
I haven't been able to find any other sources indicating one way or the other.
Is this true? If so, why, and is it still true for Hibernate 4.x? And what context sessions are intended for production use?
Hibernate supports these session management options:
(jta) org.hibernate.context.JTASessionContext: current sessions are tracked and scoped by a JTA transaction. The processing here is exactly the same as in the older JTA-only approach.
(thread) org.hibernate.context.ThreadLocalSessionContext:current sessions are tracked by thread of execution.
(managed) org.hibernate.context.ManagedSessionContext: current sessions are tracked by thread of execution. However, you are responsible to bind and unbind a Session instance with static methods on this class: it does not open, flush, or close a Session.
See: http://docs.jboss.org/hibernate/orm/5.0/userGuide/en-US/html_single/#architecture-current-session
Older implementations that used Hibernate directly often use a "thread per session" model even though they aren't recommended now.
I have a web application spread across multiple modules in different JSP pages. Currently I use different oracle connection objects across these pages due to scope limitations. I now need to rollback database transactions done on any of the JSP pages in a central JSP display page on button click. But database rollback requires an associated connection object.
I thought of maintaining only one connection object, adding it to the list of session variables and dereferencing it when needed. By doing this, I can rollback database transactions done in any page from the central display page. Kindly let me know if the above is feasible.
What I'd try is to create a singleton class that provides you the needed connection. I'd try a pool but if not, just a singleton would work somehow. When you ask for rollback, recover the connection from the class and do the rollback (or ask the class to do that for you). If you prefere a pool, then iterate over the active connections and do rollback.
Opening connections inside jsp is not very good idea. Try to isolate the logic from the pages as much as possible. Instantiating classes could be a small step to accomplish this.
Hope this helps.
I'm writing a web app that supports multiple users. Each user has their own database - using H2. all database schemas are the same.
I wish to use Spring + Hibernate for this application.
So I'm stuck at how to associate a user's database with that user - maybe associated it in the HTTPSession, and extend spring's AbstractRoutingDataSource? but wouldn't this effect Hibernate's cache? Another way is to have a SessionFactory with each datasource, even though every datasource's schema is the same... so I see that as a waste.
Anyways selecting the datasource needs to be dynamic - they can't be pre-configured in context files, as each new user will have its own database created. Is there any existing frameworks/solutions?
I don't know too much about Hibernate Shards, maybe that works?
I might be wrong about the (strict) need to have one SessionFactory per database, as suggested by some resources:
Dynamic DataSource Routing
I'll take some time to re-read everything tomorrow (I didn't get all the details to be honest) and to fully understand the implications of such a setup (although it seems clear that it will break the second-level cache). I'll come back on this later.
I'm writing a web app that supports multiple users. Each user has their own database - using H2. all database schemas are the same.
I wonder how this will scale... How many users do you have? How do you run H2, what mode?
So I'm stuck at how to associate a user's database with that user - maybe associated it in the HTTPSession, and extend spring's AbstractRoutingDataSource?
You'll have to build a SessionFactory per user and associate it to the logged user (in a Map, using the login as key) and then obtain a Session from a given SessionFactory. Binding the lifecycle of the SessionFactory to the HTTP session seems to be a good idea (to save some memory) but I am not sure Spring will be very helpful here. I might be wrong but a variation of the HibernateUtil class and a fully programmatic approach looks easier. I'm not sure you'll need multiple connections per user by the way.
but wouldn't this effect Hibernate's cache?
What cache?
Another way is to have a SessionFactory with each datasource, even though every datasource's schema is the same... so I see that as a waste.
Oh, it's a waste, but that's what you want to do (one database per user). And you don't have the choice (you need one SessionFactory per datadabase). Why do you need one database per user actually? Are you sure this is a wise decision? As already hinted, this means much troubles, won't scale well, adds complexity, etc. Why not using a single database and associating data to the user?
Anyways selecting the datasource needs to be dynamic - they can't be pre-configured in context files, as each new user will have its own database created. Is there any existing frameworks/solutions?
Not to my knowledge. Which is also why I think you'll have to do everything programatically.
I don't know too much about Hibernate Shards, maybe that works?
Given the dynamic needs of your application, I don't see how it could help.
This may help you:
Dynamic Datasource via Spring using HotSwappableTargetSource
Hibernate + Spring using multiple datasources?
Thanks to the help from the 2 people (Pascal and org.life.java)!
It is possible, but with some problems: e.g. the hibernate 2nd level cache/query cache.
This link supplied by Pascal is a very good resource:
http://www.jroller.com/kenwdelong/entry/horizontal_database_partitioning_with_spring.
My main motivation for giving each user a separate database is because the data is likely to grow rapidly, thus horizontal partitioning is required.
I created one web application so i want to store my past logged user name list for comparing new users which are going to login. so how i do that by using ServletContext ?
or is there any other way?
In JSF, application scoped managed beans are stored in the servletcontext. So, you could basically just create and declare an application scoped managed bean and put the list in there.
However, there are probably better ways for the particular functional requirement which is yet unclear in the question. At least, implementing a HttpSessionListener or HttpSessionBindingListener is probably a better idea since logins are usually coupled to the HttpSession.
Here are several examples:
How to invalidate session when user logs in twice?
How to check who's online?