> > Is it not the default propagation setting?
Yes you are correct. In what way "to use the same TransactionManager"? The same > TransactionManager spring bean? Or the same TransactionManager spring bean > instance? I meant instance. Again I am not sure if this is enough, Mixing manual and spring managed transaction goes a bit above my transaction management experience. Lars. On Thu, Apr 24, 2008 at 2:25 PM, Stefan Selariu <[EMAIL PROTECTED]> wrote: > No, the propagation was not set to REQUIRED. Is it not the default > propagation setting? > In what way "to use the same TransactionManager"? The same > TransactionManager spring bean? Or the same TransactionManager spring > bean instance? > > Thanks. > Stefan > > > On Thu, 2008-04-24 at 14:03 +0200, lars vonk wrote: > > Well it technically shouldn't matter if you use the wicket-spring module > I > > guess. > > It think it matters that you use the same TransactionManager and the > correct > > Propagation behavior (REQUIRED iirc). Did you use the same > > transactionmanager in your previous attempt and what was the propagation > > setting you used? > > > > For wicket-spring see http://cwiki.apache.org/WICKET/spring.html, I > would > > suggest you use the annotation based approach. > > > > On Thu, Apr 24, 2008 at 1:55 PM, Stefan Selariu <[EMAIL PROTECTED] > > > > wrote: > > > > > I tried this approach but without the wicket-spring module, and it > > > didn't work (No spring web application and no springbean annotations). > > > Maybe it works this way. I'll give it a try (but I'm not very sure > that > > > it helps since spring loses the transactional context, or at least so > I > > > think) > > > Is there an maven archetype for a wicket-spring project? > > > Where is the documentation for wicket-spring? > > > > > > Many thanks :) > > > Stefan > > > > > > > > > On Thu, 2008-04-24 at 13:36 +0200, lars vonk wrote: > > > > I wouldn't advice you to do it in the requestcycle for the reasons > you > > > > already describe yourself: > > > > > > > > - Too cumbersome > > > > - All request are then in a Transaction (might no be a problem > though). > > > > - How to detect that a rollback is needed. > > > > > > > > You could still use Spring transaction though: This could be a > possible > > > > implementation, but I don't know if this is rock solid especially > the > > > > rollback I am not sure about. This approach will enable nested > > > transaction > > > > IHMO since it still uses the spring configured transactions. > > > > > > > > class TransactionalRequestCycle extends WebRequestCycle { > > > > > > > > @SpringBean private TransactionManager txManager > > > > > > > > private TransactionStatus status; > > > > > > > > public TransactionRequestCycle() { > > > > // this will inject the txManager from the spring context. > > > > InjectorHolder.getInjector().inject(this); > > > > DefaultTransactionDefinition def = new > > > DefaultTransactionDefinition(); > > > > def.setPropagationBehavior(...); > > > > } > > > > > > > > protected void onBeginRequest() { > > > > status = txManager.getTransaction(def); > > > > } > > > > > > > > protected void onEndRequest() { > > > > txManager.commit(status); > > > > } > > > > protected void onRuntimeException() { > > > > if(status != null) > > > > txManager.rollback(status); > > > > } > > > > } > > > > > > > > On Thu, Apr 24, 2008 at 1:18 PM, Stefan Selariu < > [EMAIL PROTECTED] > > > > > > > > wrote: > > > > > > > > > Thanks for your answer, but sadly this is not possible. > > > > > I cannot group the beans in one service because the beans are > invoked > > > > > from different wicket components. > > > > > I need the request cycle to be transactional because on the submit > > > event > > > > > one component calls the required transactional service and at > render > > > > > time the page components sometimes need to invoke other > transactional > > > > > beans to complete the rendering. > > > > > > > > > > If I quit using spring's transactions support I could use > > > onBeginRequest > > > > > and onEndRequest to start and close the transaction. This approach > is > > > > > very limited (no nested transactions, very complicated transaction > > > > > exceptions handling, the spring beans need to be aware of the > > > > > transactions) and I don't like it :) > > > > > > > > > > Has anyone an idea why RequestCycle is a class and not an > interface? > > > > > This is a problem in my case :( > > > > > > > > > > Thanks again. > > > > > Stefan > > > > > > > > > > On Thu, 2008-04-24 at 11:03 +0200, lars vonk wrote: > > > > > > I would advice you to group the transactional beans in one > Service, > > > > > define > > > > > > that service in Spring and make it transactional. By using the > > > proper > > > > > > Transaction Propagation levels the "wrapped" beans can use > existing > > > > > > transactions if there is one. > > > > > > > > > > > > See > > > > > > > > > > > > > > > http://static.springframework.org/spring/docs/2.5.x/reference/transaction.htmlfor > > > > > > more info on Spring and Transactions. > > > > > > > > > > > > Lars > > > > > > > > > > > > > > > > > > On Thu, Apr 24, 2008 at 10:01 AM, Stefan Selariu < > > > > > [EMAIL PROTECTED]> > > > > > > wrote: > > > > > > > > > > > > > Hi! > > > > > > > > > > > > > > I need to call inside a request cycle an unknown number of > > > > > transactional > > > > > > > spring beans. How can I call those beans within the same > > > transaction? > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > 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] > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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] > >
