views:

176

answers:

3

when using hibernate with spring, can someone explain how the session unit of work and transactions are handled?

  1. is the transaction started at the beginning of the page request, and committed at the end?
  2. can I have multiple db calls per request, that each have different transaction levels? e.g. some are left as default, while others are read-uncommitted?
+1  A: 

It's usually configured declaratively with aspect oriented programming (AOP). You can define what beans, classes, packages or methods require transactions and Spring will provide it in a fashion similar to EJBs. Thanks to AOP you have full control over what exactly and how is wrapped into transactions.

Read more about it here: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/transaction.html#transaction-declarative

Konrad Garus
+1  A: 

to your questions:

1-is the transaction started at the beginning of the page request, and committed at the end?

Not exactly. the usual workflow of spring MVC is:

requestDispatcher->Controller->Service call(transaction starts and ends here)

Services may invoke Daos, Daos will talk to Datastore via Hibernate.

A transaction can continue living after the http response. e.g. service run in a thread.

2-can I have multiple db calls per request, that each have different transaction levels? e.g. some are left as default, while others are read-uncommitted?

Yes certainly you can. let's say, your application does a migration job. a request says "start migration!" Then your service will read data via source database, and do some magic base on your migration logic, finally write to target database, and commit the transaction.

Kent
+2  A: 

is the transaction started at the beginning of the page request, and committed at the end?

In a web application, opening / closing the Session is usually done using the "Open Session in View" pattern. Spring comes with a OpenSessionInViewFilter or an OpenSessionInViewInterceptor for this. Both make Hibernate Sessions available via the current thread, which will be autodetected by transaction managers. It is suitable for service layer transactions via HibernateTransactionManager or JtaTransactionManager as well as for non-transactional execution (if configured appropriately).

Transaction demarcation is usually done at the service methods level, using Spring AOP to wrap them inside transactions.

can I have multiple db calls per request, that each have different transaction levels? e.g. some are left as default, while others are read-uncommitted?

You can have nested transactions with different isolation levels. Refer to the Transaction Management chapter.

Pascal Thivent
@Pascal: Thank you for your contribution! Actually, every time I need something special, I see your comments. Actually, I was searching for the way to expand the lifetime of Hibernate session across two transactions (e.g. two `@Transactional` methods) to preserve L1 cache, and I haven't thought about helpers mentioned in your post that bind the session to HTTP request. What can you advise for example, if I want to achieve the same for the JAX-WS WebService exposed by `SimpleJaxWsServiceExporter` (when the request/response flow is not managed by Spring)?
dma_k