Robert,
Thanks for the feedback. I took a look at Spring. It seems interesting but I decided to pass on it right now rather than take the time to get up to speed on yet another framework.
I did take a look at ThreadLocal, however, and I think this will be perfect for what I need. In fact I found an article that describes how to use ThreadLocal and uses JDBC connections in one of their examples (http://www-106.ibm.com/developerworks/java/library/j-threads3.html).
I had hear people mention ThreadLocal before but I never really knew what it was about. Now that I've taken a look at it I'm pretty impressed. It was interesting to learn that the initial implementation of ThreadLocal was very similar to what I was proposing here. (Apparently, It has since evolved to be much more efficient than the initial implementation.)
I'm allways glad to check with others before embarking on a solution like this. Often times I am on the right track but the collective experience of programmers can usually come up with a superior solution (much like Struts vs. my own efforts before discovering Struts.)
Thanks again!
sean
----- Original Message ----- From: "Robert Taylor" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Friday, September 17, 2004 3:17 PM
Subject: RE: Idea for chain and DB transactions
Sean, have you looked at Spring? It uses AOP and you can set up transactions declaratively.
I'm just starting to investigate using Spring and I'm really impressed.
Like you I had a requirement to demarcate transactions at a high level so that
all business objects within the transaction were subject to the same transaction
semantics unless a business object explicitely needed to be isolated.
I ended up creating a Transaction framework of sorts which uses ThreadLocal to
propogate the Connection to my DAO's. All DAO's that need to be included in a
transaction had to subclass a TransactionalDAO which "knew" how to access the
current TransactionContext from ThreadLocal.
It has worked for a couple years now, but its not that clean or elegant.
That's why I was so excited to read about Spring and IoC. It does all that stuff
for you.
robert
-----Original Message----- From: Sean Schofield [mailto:[EMAIL PROTECTED] Sent: Friday, September 17, 2004 2:44 PM To: [EMAIL PROTECTED] Subject: Idea for chain and DB transactions
I have a problem and a proposed solution. I would greatly appreciate any feedback about the proposed solution.
Problem:
=======
I'm currently using a Struts application with a connection pool (using DBCP as supplied by Tomat). When a database
update is needed, the Struts actions will call the facade which will talk to my service layer (currently POJO's which
handle business logic.) My service layer in turn talks to the appropriate DAO. Each of these DAO's extends from a
common abstract class that provides basic functionality including obtaining a connection from the DataSource (via the
pool). A key aspect of my design is that some updates are in distinct areas of the database and so I have different
DAO's for each area (ex. one for "workflow" on for "document.")
As currently implemented I am unable to take advantage of transactions because the two DAOs will be getting a connection
indepently from the pool and they will most likely not obtain the connection each time. If I could just get the same
connection each time, then I could use setAutoCommit(false).
Proposed Solution:
==============
I'm thinking I could set up a few chains for the various kind of updates. The chains would be called by the POJO service
layer (instead of calling the DAO's directly.) The first Command in the chain would be to indentify all database updates
in the chain as needing transactions. This would be done through a static method on a new object called
TransactionManager. Basically I would have a hashtable that would maintain connections for the duration of the chain.
The connections would be stored by the current thread (use that as the key to the table.)
Then when a command down the line needs a database connection, it would first check to see if there is one already set
aside for it to use. Actually the command would call the DAO and the DAO would check. The command would also be
decorated by a custom wrapper so that if the DAO's try to close the connection, I'll ignore it. Then when the chain does
the post processing in reverse order. So the last clean up step will be to check for my custom DAOException. If there
is one, then rollback, otherwise commit. Finally, the connection is removed from the TransactionManager.
I think this might be crazy enough to work. I know we could allways use EJB and get transactions but that might be
overkill since the volume is very light (this is custom software for a government agency not ecommerce.) Please let me
know what you think. A big question I have is about storing and retrieving the datbase connection using the current
thread as the key to a hashtable. Also, I know that I will have to be careful with thread synchronization.
Thanks, sean
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
