You could look at how Spring implements their declarative transaction handling.
On Thu, 2007-05-31 at 08:14 -0500, Sudhir, Sudhir (Contractor) wrote: > Thanks Clinton, > > I am curious about the second approach, I don’t think I quite got what > you are saying there…is there an example that you can illustrate or > point to? > > > > Thanks, > > Sudhir > > > > From: Clinton Begin [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 30, 2007 8:31 PM > To: user-java@ibatis.apache.org > Subject: Re: Nested transactions? > > > > > The DAO framework is smart enough to deal with that. But yeah, you > need to move your transaction management out of those methods. I > understand the challenge there. There are at least 3 possible > solutions: > > 1) Move the transaction control up to the web tier or at least higher > than the service layer. Servlet filters (or struts/webwork filters > work well fot this). This is the simplest approach and nobody should > scare you out of high level transaction scoping...transactions should > be as broadly scoped as possible. An easy way to do it is start a > transaction for all POST requests, but not for GET requests -- handle > odd cases as appropriate. > > 2) Build your own filtering mechanism into your service layer. It's > fairly simple, you can copy the dynamic proxy code from the DAO > manager that handles automatic transactions. Basically the first > service method called becomes the transaction scope, regardless of how > many other services or DAOs it calls. It can get a little tricky > around the nested stuff (think ThreadLocal) and exception handling, > but this is the way I almost always do it for clients. > > 3) Use Spring, it does all of the above. And Spring 2 has simplified > configuration quite a bit. :-) > > Cheers, > Clinton > > On 5/30/07, Sudhir, Sudhir (Contractor) <[EMAIL PROTECTED]> wrote: > > Thanks, > > The only issue that you run into quite often is that you need both > composite services as well as more fine grained services and both > these kinds of services need to be "transaction aware". So you end of > creating "layers on top of the service layer" to delegate and allow > for transactions. Not a problem other than the fact not you have a > set of methods that do nothing but start and end transactions, just > becomes cumbersome I guess. > > So essentially if I wanted to do something to the effect, is my only > option to re-factor such behavior into a different method?: > > > ServiceClass1 > > > public void doSomething() { > > > try { > > > daoManager.startTransaction(); > > > // Write some stuff to a database > > > daoManager.commitTransaction(); > > > } catch (Exception e) { > > > throw e; > > > } finally { > > > daoManager.endTransaction(); > > > } > > > } > > > > > > ServiceClass2 > > > public void doSomethingElse() { > > > try { > > > daoManager.startTransaction(); > > > ServiceClass1 sc1 = new ServiceClass1(); > > > sc1.doSomething(); > > > // Write some stuff to a database > > > daoManager.commitTransaction(); > > > } catch (Exception e) { > > > throw e; > > > } finally { > > > daoManager.endTransaction(); > > > } > > > } > > Thanks, > > -Sudhir > > > > From: Clinton Begin [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 30, 2007 5:47 PM > To: user-java@ibatis.apache.org > Subject: Re: Nested transactions? > > > > > Nested transactions are evil*. iBATIS has a strict policy to use its > powers only for good. So unfortunately no. > > :-) > > Clinton > > * Why? See the 'A' in ACID. http://en.wikipedia.org/wiki/ACID > > On 5/30/07, Sudhir, Sudhir (Contractor) <[EMAIL PROTECTED]> > wrote: > > Does iBatis support nested transactions? > > -Sudhir > ----------------------------------------- > > This message may contain confidential information. If you are not > the intended recipient, please notify the sender immediately and > delete this email from your system. > > > > > > > >
