I'm using Hibernate with Spring on Tomcat. I've been reading and re-reading the oft pointed to JBoss wiki page on the topic, and that has been helpful. But it leaves me with some questions.
The idea of starting a transaction for every request troubles me. I guess I could limit the filter to certain controllers -- maybe put all my controllers that need a transaction under a pseudo "tx" path or something. But isn't it a bad idea to use transactions if you don't know if you're going to need one? And if I'm just doing reads in some request -- reads that very likely may come from a cache -- aren't I better off without a transaction?
I've read posts mentioning how they handled the transactions at the service layer, and I'd like to do this with Spring. But then what does the filter code look like? I still want the session available in my view for some lazy loading.
If all I have to do is call sessionFactory.getCurrentSession() in my filter, how does it get "freed" back to the session factory for re-use? (I expected to see a session.close() or something, even when using transactions.) Who is telling the session factory that that session can be reused?
Perhaps it's the beginTransaction() call that binds a given database connection to a given session for the duration of a request? Otherwise, a session pulls db connections from the pool as needed, right?
Thanks for your patience with all my questions.
(And if your answer is going to be a link to the Spring documentation, you'll just make me cry. You don't want that, do you? I'll pay real money if people would stop answering Spring-related questions that way.)
Your concerns are valid, the solution provided on the wiki page is too simplistic. The transaction should not be managed at the web layer - it should be handled at the service layer.
The correct implementation would open a session and bind it to a thread in the filter. No transaction is started. The session is put in flush mode never - read only mode. A service call would set the session to flush mode auto & start / commit the transaction. Once the service method finishes the session flush mode is reverted back to never.
There is also an option to not open the session in the filter. Each service layer call would open a separate session & transaction - after the service call is done the session is not closed, but registered for deferred close. The session will be closed after the web request processing is complete.
Spring provides OpensessionInViewFilter which works as described above. So ignore the jboss wiki article and just configure the OpensessionInViewFilter - everything will be fine.
SessionFactory.getCurrentSession() - internally creates and assigns the session to a thread local. Each request / thread will have its own session. Once the web request processing is complete the session will be closed. From within your code you just need to use SessionFactory.getCurrentSession() and don't have to close it. The code sample on the jboss wiki page is wrong - it should have a SessionFactory.getCurrentSession().close() in the finally block. Or they might be using JTA transaction and configured hibernate to open/close session in conjunction with the JTA transaction.
It is not a problem if the filter creates a session for every request, because the sessions are coming from a session pool, and they will be reused. From the view of the OS, nothing happens.
A hibernate session is, by the fact, a tcp (or socket/pipe) connection to the database server. The cost of the db conn creation is very dependent from the sql type (postgresql is notably bad in this, altough it is very good in every anything). But it doesn't means really anything, because hibernate reuses the database connections.
The simple hibernate filter solution starts a new transaction on the session for every requests, too. It is transaction from the view of the SQL: it is a "BEGIN" and "COMMIT" query. It is always costly, and this should be reduced.
IMHO a possible solution were, if the transactions were started only at the first query of the current request. Maybe spring has something usable for this.
Related
If i add spring-session jdbc to my vaadin-spring-boot-application the application is very slow and does a full page reload after a few seconds. Everything else looks like it is working normally.
I do not notice the problem and I have been researching on this issue for a few days and got this Github issue and Vaadin microservices configuration But in these, I did not find a suitable solution to solve this problem, Any one can give me an true example to implemention Spring sessions on Vaadin?
Regards.
Session replication schemes like spring-session assumes that the session is relatively small and that the content isn't sensitive to concurrent modification from multiple request threads. Neither of those assumptions hold true for a typical Vaadin application.
The first problem is that there's typically between 100KB and 10MB of data in the session that needs to be fetched from the database, deserialized, updated and then again serialized and stored in the database for each request. The second problem is that Vaadin stores a lock instance in the session and uses that to ensure there aren't multiple request threads using the same session concurrently.
To serialize a session to persistent storage, you thus need to ensure your load balancer uses sticky sessions and typically also use a high performance solution such as Hazelcast rather than just deserializing and serializing individually for each request.
For more details, you can have a look at these two posts:
https://vaadin.com/learn/tutorials/hazelcast
https://vaadin.com/blog/session-replication-in-the-world-of-vaadin
If I have a number of Grails domain objects that I do not want to save just yet, but still access them throughout my application, is it wise to store them in the Grails / Hibernate session (especially as regards peformance)? If not, what is the alternative?
What do you mean by the grails / hibernate session?
If you really mean the Hibernate session, adding an object to it will provoke the object to be saved automatically when the session is flushed (unless the object doesn't validate, in that case it will be lost once the session is discarded). A session is created and discared per request.
If you mean the session object that gets automatically injected into controllers and views, it's nor grails neither Hibernate specific, but just the old, plain HttpSession from the Servlet specification (see http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html).
You can use that to store any kind of object if you need to access them across multiple requests of the same client. Meaning the session is private to a given client (who identifies it throught the jsessionid cookie) and survives multiple requests. If you don't need the multiple request bit, adding them as a request attribute would suffice.
Putting things in the session is generally fine and fast (since by default is based on memory), but it will increase the memory footprint of the application if abused, and will prevent horizontal scaling (i.e deploying the same application in multiple instances) unless sticky session mechanisms are used (or the session is persisted).
Bear in mind though that grails uses a new Hibernate session per request (not an Http session :), so if you add objects that are attached to a Hibernate session to the Http session, and then the Hibernate session is closed, you might encounter problems. This shouldn't affect non-saved objects (they don't come from a Hibernate session), but it might affect their associations (other domain classes that do come from the database and therefore a Hibernate session). If that's the case, you might need to re-attach them. See https://grails.github.io/grails-doc/latest/ref/Domain%20Classes/attach.html
Also, if the session is invalidated (because the user logs out, or the server is re-deployed) everything that was stored in there will be gone.
If you don't want to rely on sessions at all, you can create your own a MemoryBasedStoreService service and use a ConcurrentHashMap or a similar mechanism to store and retrieve the objects. Since services are singleton in Grails, you can use it across the whole application, regardless of requests or clients - as long as your application is deployed in a single instance of course :).
I am working on a large complicated Tapestry service. It generally works but sometimes when running for a while the session it is in will get invalidated, and it will send an error. There is nothing about this service that should need the session but sometimes it depends on a service that depends on a service that "needs" the session.
I want to pragmatically invalidate the session in my tests, so I can protect against regression. Ideally I would do this without killing the session in the production code, which is how I am testing it now.
Specificly, we are testing the service by running the server and making http calls, and also by extending TapestryIoCTestCase. I can't think of any clean way to invalidate a session from the http client tests. and the Mock session created for TapestryIoCTestCase does not support invalidation.
I have looked into setting the session time-out in the tests, but I was hoping for something more direct.
Thanks
e for instance someone at somepoint wanted to set the locale in one of our dependencies
java.lang.IllegalStateException: setAttribute: Session [31943F300613D2105C9AF8602397557D] has already been invalidated
at org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1437)
at org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1402)
at org.apache.catalina.session.StandardSessionFacade.setAttribute(StandardSessionFacade.java:156)
at org.apache.tapestry5.internal.services.SessionImpl.setAttribute(SessionImpl.java:67)
at org.apache.tapestry5.internal.services.SessionApplicationStatePersistenceStrategy.set(SessionApplicationStatePersistenceStrategy.java:68)
at $ApplicationStatePersistenceStrategy_13c1cafe292.set($ApplicationStatePersistenceStrategy_13c1cafe292.java)
at org.apache.tapestry5.internal.services.ApplicationStateManagerImpl$ApplicationStateAdapter.set(ApplicationStateManagerImpl.java:50)
at org.apache.tapestry5.internal.services.ApplicationStateManagerImpl.set(ApplicationStateManagerImpl.java:138)
at $ApplicationStateManager_13c1cafe272.set($ApplicationStateManager_13c1cafe272.java)
I'm assuming you are referring to the HttpSession which can be invalidated by calling HttpSession.invalidate(). Though in all honesty your question provides too little information for a proper answer. What is your setup? What have you tried? What does your code look like? Are you mocking your Servlet Container? Etc...
Questions without code are hard to answer.
In a web application, I'm using JPA entities to persist (and retrieve) my domain objects to (and from) an underlying database.
These JPA entities are kept "hot" in an in-memory cache structure (think of a Map<UniqueID, Entity>) for the whole running time of the web application.
So I'm doing a request to my web application, an entity gets loaded from the repository. This entity gets put into the in-memory cache structure. For the whole lifetime of this request, I can happily access any fields of this entity. During this first request, also lazily-loading relationships to other entities works fine, even in my View: I'm successfully using the Open-Session-in-View pattern (via Spring's OpenEntityManagerInViewInterceptor).
The first request has ended.
I'm doing the next request to my web application. This request asks for another entity. This entity is already in the in-memory cache structure, so it gets loaded from there. From this entity, I try to access a field that should lazily-load relationships to other entities. This unfortunately causes the obnoxious org.hibernate.LazyInitializationException: could not initialize proxy - no Session (I'm using Hibernate as my underlying JPA implementation)
To my understanding, this exception stems from the fact that after the first request has ended, JPA/Hibernate has ended any JPA sessions, yet entities in my in-memory cache structure still expect any of these sessions to exist; at the moment that the next request causes to fire the mechanism for lazily-loading entities, the lazily-loading mechanism can't find any no-longer existing session.
What are solutions to my problem?
One of solutions is to reattach the entity to session at the beginning of the second request using Session.update().
Another solution is to use the second level cache in Hibernate instead of your own solution. It should be much more reliable than any home-grown caching mechanism.
Basically, you cannot keep sessions alive across HTTP requests because this would mean to keep the transaction open between requests.
I think the only solution (apart detecting yourself what is loaded and what is not) is to fetch the whole entity before putting it in your cache. IMHO you shouldn't put partially loaded objects in a cache. If you don't want to load the whole object the first time, you might use separate caches for the objects relationships.
If you want, you might also consider enabling Hibernate cache as proposed by #Adam, but I don't think it would work well with lady-loaded fields.
You are getting this exception because your object is detached from current session. You have to re-attach this object to current session before assessing it
session.update(object);
You can read details here
Today at work I had a discussion with my co-workers and my boss about stateless / stateful beans (we just finished a project using JSF, it was the first time anyone at this company did something JSF related) and my boss said that he doesn't really like Session scoped beans (or even conversation / KeepAlive scoped ones). One of his arguments was that if we have for example 4 Tomcats and there is a request from the user then we aren't really sure that it will be "captured" by the same Tomcat every single time and the problem is that if during the first time a request comes and a session bean is created it's created only on that one Tomcat and the others don't know about it.
One of the solutions he mentioned was a so called "sticky session" which enforces requests from a given user to be handled by the same Tomcat every time. A second solution according to him would be storing all the data in the "view", but that would mean storing the whole state in the POST, somehow I don't really like that idea. Then he mentioned storing the state in the DB and querying it if a request that requires it arrives. I thought that it would be a really huge performance hit, but he said that it really wouldn't be a concern since the DBs should be prepared for such tasks.
The last solution which I'm interested in was the Terracotta Server which, from what he told us, is supposed to store the session bean for all Tomcats (which are synchronized with it and then if a requests comes in they look for session beans inside Terracotta). Seems kinda cool and scalable, but he said that he didn't really see it ever used in large professional systems, is that right? I tried some info on it but failed, is there something wrong with Terracotta that stops people from using it?
It is used by professionals, just look a their customers page.
http://www.terracotta.org/company/customers?src=/index.html