Re: TransactionManager continuations

Thank you for the detailed configs but there is one detail I am  
unclear on. I seems like you are forwarding transactions on to other  
TransactionManagers and the last one in line sends the response.

I was specifically interested in the idea of a participant that  
returned PAUSE. Before PAUSE you can send the transaction out for  
other processing but how do you "get it back" and continue on where  
you left off? Where does second TransactionManager send it back to?

The reason I am asking is it would simplify a problem I have if I  
could shoot off a Context to another TransactionTananger, pause the  
main transaction,  dittle the Context in the second  
TransactionManager, and then send it back to the original  
TransactionManager to continue processing.

Is that in your example somewhere that I am missing? I also looked at  
TestPauseParticipant.java. Is it simply a matter of forwarding it back  
to the original TransactionManager queue sometime after the PAUASE? If  
so, is the whole Context replaced with the new one? How are things  
matched up? I am having a hard time visualizing the process from  
looking at the source.

-Anthony

On Apr 30, 2008, at 9:17 AM, Andy Orrock wrote:

> Anthony -
>
> This is not a direct answer to your question, but provides some  
> mechanical
> instructions to list readers...
>
> ** Also, for an explanation as to why we use Continuations in our jPOS
> implementations, refer to my write-up here:
> http://continuations.notlong.com
>
> Our main server listens to the incoming port like this (full  
> contents of our
> 50_ev_server.xml)
>
> <ev-server class="org.jpos.ev.Server" logger="Q2">
> <property name="port" value="33000" />
> <property name="space" value="tspace:default" />
> <property name="queue" value="RACEV.TXN" />
> <property name="timeout" value="60000" />
> </ev-server>
>
> Then, in our *main* transaction manager (30_ev_txnmgr.xml), we take  
> items
> off that queue like this:
>
> <ev-txnmgr class="org.jpos.transaction.TransactionManager"  
> logger="Q2">
> <property name="sessions" value="96" />
> <property name="space" value="tspace:default" />
> <property name="queue" value="RACEV.TXN" />
> <property name="debug" value="false" />
>
> (those are the production settings, BTW)
>
> Then, within the context of a 'switch' participant in 30_ev_txnmgr, we
> choose to move the processing of some transactions to another
> TransactionManager:
>
> <!-- GreenDot Transactions -->
> <property name="S.43" value="ForwardToGreenDotTxnMgr" />
> <property name="S.44" value="ForwardToGreenDotTxnMgr" />
> <property name="S.45" value="ForwardToGreenDotTxnMgr" />
>
> Then, later in 30_ev_txnmgr, we have this group:
>
> <group name="ForwardToGreenDotTxnMgr">
> <participant class="org.jpos.transaction.Forward">
> <property name="queue" value="GreenDot.TXN" />
> <property name="timeout" value="60000" />
> </participant>
> </group>
>
> Then, finally, we have 30_greendot_txnmgr.xml, which starts off like  
> this...
>
> <greendot-txnmgr class="org.jpos.transaction.TransactionManager"
> logger="Q2">
> <property name="sessions" value="16" />
> <property name="queue" value="GreenDot.TXN" />
> <property name="debug" value="false" />
>
> <participant class="org.jpos.ev.Switch" logger="Q2" realm="switch">
> <property name="S.43" value="CreateSV GDotActivate" />
> <property name="S.44" value="CreateSV GDotRefresh" />
> <property name="S.45" value="CreateSV GDotDeactivate" />
> </participant>
>
> Andy Orrock
>
> -----Original Message-----
> From: jpos-dev@...
[mailto:jpos-dev@...] On  
> Behalf
> Of Anthony Schexnaildre
> Sent: Wednesday, April 30, 2008 7:53 AM
> To: jpos-dev@...
> Subject: Re: [jpos-dev] TransactionManager continuations
>
> That's great news. Can you give some hints on it's expected usage/
> behavior? What does it do magically and where is lifting required? I
> am a little unsure how transactions get matched up, etc.
>
> -Anthony
>
> On Apr 29, 2008, at 1:21 PM, Alejandro Revilla wrote:
>
> > >
> > > Just a follow up, what progress has been made on this issue in a
> > year?
> > > I thought about giving continuations a try but wanted to see if  
> the
> > > solution was ever baked into jPOS or if anyone can give me some
> > hints
> > > on an implementation that they found successful?
> > >
> > It is fully operational. We had extensive tests in a high demanding
> > (900
> > TPS) application last year. You may be lucky and able to find some  
> new
> > bugs, but it is certainly ready to give it a try.
> >
> > If I recall correctly, this team were using just 5 TM threads to run
> > their simulation.
> >
> > --Alejandro
> >
> >
> >
>
> [Non-text portions of this message have been removed]
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
> 

[Non-text portions of this message have been removed]

------------------------------------