you need to surround your code with something like ths:
PlatformTransactionManager ptm = (PlatformTransactionManager)ctx
.getBean("transactionManager");
TransactionStatus txn = ptm.getTransaction(new DefaultTransactionDefinition());
...
ptm.commit/rollback(txn)
whether you do this in onclick() or on request cycle is up to you. but
like others have mentioned, you should probably do this lazily so that
not every request starts a transaction unless it needs it.
it is too bad spring doesnt provide a Filter to do this, a
single-transaction-per-request is a pretty common pattern.
-igor
On Thu, Apr 24, 2008 at 5:56 AM, Stefan Selariu <[EMAIL PROTECTED]> wrote:
> I have no idea how to use tell spring which transaction manager instance
> to use.
> I'll try to put the request scope for it.
>
> I managed to reconfigure the application with wicket-spring, but I have
> no idea if the same transaction is used since the received session is a
> spring proxy. I'll dig some more :)
>
> Thanks for your help.
> Stefan
>
>
>
>
> On Thu, 2008-04-24 at 14:33 +0200, lars vonk wrote:
> > >
> > > 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]
> > >
> > >
>
>
> ---------------------------------------------------------------------
> 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]
