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]

Reply via email to