On May 11, 2005, at 12:09 PM, Konstantin Iignatyev wrote:
Erik Hatcher wrote:
IMO a proxy wrapped POJO is more transparent because it works properly no matter who and why calls its methods. My trick works with the assumption
I don't see how it'd be transparent. What is more transparent than a listener that doesn't have any explicit commits or rollbacks in it? In fact, my Tapestry code will have no direct use of Cayenne's API if all goes as planned.
that transactions starts when a thread enters first DAO layer method and finishes when the thread leaves it. It also correctly propagates the same transaction to all others call of DAO layer if necessary.
So, I do not know details of your implementation, but generally speaking if your object has business methods and they invoke DAO layer, then my trick works just fine.
For the sake of discussion, view the Tapestry listener method as the DAO layer method. I want to wrap a transaction around that.
The question is, how can you wrap this transaction boundary around Tapestry listener invocations?
There is not a way to intercept listener method invocations with HiveMind that I know of. If you know of a way, could you please share?The trick is to intercept invocations of all or selected methods on certain DAO objects (singletons) no matter who invokes them.
That is just a matter of using proper HM interceptor, pretty much like the one I have used to compare performance of AOP
http://kgionline.com/articles/aop_1/aop_perf.jsp , scroll down to HM case.
Let me repeat one more time - the trick completely decouples DAO from all its users (UI, batch, WS, etc).
Actually all those DAOs become equivalents of Stateless Session Beans where every method is transactional.
And every method invocation is followed by a commit? I want to be a bit less fine grained than that, and make several business method calls possibly before a commit occurs. I assume that is what you do with yours, I'm just not clear on that based on what you just said.
That may or may not work for you, but I certainly discourage explicit transaction management in UI.
I'm definitely working to avoid explicit transaction management, that is the crux of my issue here.
My disclaimer is that I've historically avoided the database tier as others have been much more skilled and actually enjoyed it more than I do - so I'm learning this stuff now because I'm a one-man team on my current project.
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
