Menu
▾
▴
RE: [Springframework-developer] Transaction support
|
From: <jue...@we...> - 2003-04-03 13:35:34
|
Maybe it would be easier to handle if we simply added an additional = source directory "examples" besides "src" and "test", containing the = packages you propose? I don't see a need for a separate CVS module for = "core examples", although there are arguments for it. Rod, where do you intend to put the adapted example app from the book? Another issue is where to put misc docs, but I consider the "docs" = directory used by the javadoc Ant task (it uses "docs/api", more = specifically) an appropriate location. We will probably need to = restructure the (non-API) docs when they become more organized anyway. Juergen -----Original Message----- From: Kopylenko, Dmitry [mailto:dko...@ac...] Sent: Thursday, April 03, 2003 3:11 PM To: j=FCrgen h=F6ller [werk3AT]; spring-dev-list Subject: RE: [Springframework-developer] Transaction support How about "Spring/examples" tree on CVS HEAD with package structure = somewhat like this: com.interface21.sample.<sample_module_name>.<sub_packages> ? -----Original Message----- From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...] Sent: Thursday, April 03, 2003 07:57 AM To: spring-dev-list Subject: RE: [Springframework-developer] Transaction support Dmitriy, everybody, Well, sample apps and usage docs would help a lot, of course. I'm = willing to put effort into these as soon as we decide to settle on the current = design of the transaction support. I'm not sure where to put these resources, though. Tx support = documentation could go into the package JavaDocs of the transaction package, this = would be a natural fit. But where should we put example classes? Hibernate puts = them in its net.sf.hibernate.eg package, but I'm not sure if it is a = particulary good idea to put examples in the main source tree. What do you think? Juergen -----Original Message----- From: Kopylenko, Dmitry [mailto:dko...@ac...] Sent: Thursday, April 03, 2003 2:50 PM To: j=FCrgen h=F6ller [werk3AT] Cc: 'spring-dev-list' Subject: RE: [Springframework-developer] Transaction support Juergen, guys, are you planning any sample apps/detailed usage docs (on transaction = support for example) for 0.8 release? Rod,=20 when do you think the aopalliance.org will be up and running? Thanks. Dmitriy. -----Original Message----- From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...] Sent: Thursday, April 03, 2003 07:39 AM To: spr...@li... Subject: RE: [Springframework-developer] Transaction support Rod, I guess removing the check in TransactionInterceptor and modifying the = test case accordingly will solve the issue. Now that we seem to approach a certain degree of stability in terms of transaction support too, we should actively consider releasing 0.8. = We're not really following "release early, release often" up to now... A combined developer download will be enough for the moment, I assume, = we don't really need a binary-only download before 1.0. Have you looked at = how SourceForge's release support works already? It shouldn't be hard to = figure out. Even for 0.8, we should try to raise some attention just after the = release, for example at TheServerSide. We could gain important feedback, long = enough before 1.0 to be able to still tweak the design if necessary. Juergen -----Original Message----- From: Rod Johnson [mailto:rod...@in...] Sent: Thursday, April 03, 2003 2:27 PM To: j=FCrgen h=F6ller [werk3AT]; spr...@li... Subject: Re: [Springframework-developer] Transaction support Juergen, I needed to put that check in to get the tests to pass. However, the clarification about how PlatformTransactionManager implementations = should behave would also resolve the problem (meaning I could modify the test = case, not the class). I haven't looked at your code in great detail, but from what I've seen = it looks good and I endorse the design. Regards, Rod Hi Rod, I've just seen your modifications to TransactionInterceptor. You've = added explicit programmatic rollback handling, i.e. if (status !=3D null && !status.isRollbackOnly()) { // Normal course of transaction: commit doCommit(); } else { // Handle programmatic rollback doRollback(); } where doCommit and doRollback call PlatformTransactionManager's commit = and rollback, respectively. Technically, this isn't necessary, as the PlatformTransactionManager implementation is supposed to handle this. = That way, every transaction manager client can benefit from it implicitly. Unfortunately, PlatformTransactionManager's documentation currently = doesn't state that, so I will add appropriate JavaDoc. By deriving from AbstractPlatformTransactionManager instead of = implementing PlatformTransactionManager directly, a transaction manager = implementation can benefit from the former's programmatic rollback and propagation = behavior handling. A subclass just needs to implement doCommit, doRollback, etc without having to care about such case handling that will normally be = the same (see JtaTransactionManager). All things considered, I suggest to remove the explicit check above if = you don't mind, as it is unnecessary. Generally, what do you think of the current state of the transaction support? Any limitations or inappropriate design decisions? ------------------------------------------------------- This SF.net email is sponsored by: ValueWeb:=20 Dedicated Hosting for just $79/mo with 500 GB of bandwidth!=20 No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.net email is sponsored by: ValueWeb:=20 Dedicated Hosting for just $79/mo with 500 GB of bandwidth!=20 No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
