I am a bit confused now. Might be missing some basic points. Started with programmatic transaction management in spring. In a class UserManager I inject a TransactionTemplate. This TransactionTemplate holds an DataSourceTransactionManager.
Now in the singleton UserManager I have 2 methods which should use different transaction behaviour: getUser() ---> which should use read-only transaction. insertUser() ---> which should not use read-only transactions for an obvious reason (its an insert).
I can make the behaviour of the TransactionTemplate read only with setReadOnly(true). This method is defined in the class DefaultTransactionDefinition from which TransactionTemplate inherits.
Now: When I have 2 methods in a class requiring different Transaction settings which will be exposed to multithreaded access by clients, do I need to inject 2 different Transaction Templates as members (1 with read-only other not)?
Warning: I'm extrapolating from my understanding of how HibernateTemplate works. I haven't used TransactionTemplate as I went with declarative transactions instead.
While my DAO is a singleton and it has a single HibernateTemplate instance used by all threads calling the DAO, HibernateTemplate interfaces with Hibernate by using a ThreadLocal Session. Each thread calling an HT method gets its own private Session, making the DAO thread-safe.
Also, with declarative transactions Spring again stores the transaction in a ThreadLocal making it private to the thread. When it enters a method with a txn property defined, it checks to see if the thread is already in one. If so, it uses it; otherwise it begins a new one.
I just skimmed some of the 1.2 code. TransactionTemplate has a TransactionManager that it uses to acquire the TransactionStatus and also to commit it and rollback. As DataSourceTransactionManager uses DataSourceUtils which binds the DataSource to the thread, my guess is that the txn is also bound to the thread.
Thus, just like HibernateTemplate, it seems that TransactionTemplate is a thread-safe singleton since it binds the state-holding object(s) to the thread. Again, this is conjecture on my part, so roll up your sleeves and dive into the code to verify for yourself.
posted 15 years ago
David. Thanks for the input. I am going to switch to declarative transaction management anyway. I had have no specific reason to use programatic transaction management except step-by-step learning approach. Your detailed explanation how you approach the question helps understanding.
Thus, just like HibernateTemplate, it seems that TransactionTemplate is a thread-safe singleton since it binds the state-holding object(s) to the thread.
I am going to check. If the transaction is stored in ThreadLocal (thread-safe singleton) I should be able to set the required transaction level in each business method individually. I think it'll be stored in ThreadLocal. I defintively know that in ibatis sqlmap even without spring-framework the database session is stored in ThreadLocal.
[ May 01, 2005: Message edited by: Axel Janssen ] [ May 01, 2005: Message edited by: Axel Janssen ]
posted 15 years ago
When I said, "it seems that TransactionTemplate is a thread-safe singleton," I meeant that the TransactionTemplate is a singleton at the scope of your bean since it gets a ssigned a single instance during initialization.
Given that Hibernate is pretty solid, I suspect we're right about the use of ThreadLocal. If it didn't use it, there would have been biffer fallout in the community by now. Anyway, please let us know if you get a definitive answer.