2010/4/20 Raphaël Delaporte <[email protected]>:
> Hi,
>
> Ok that's clearer for me !
>
> 1. Is there a way to explicitly commit the transaction ?
> In Oracle BPEL world, there is the checkpoint java embedded for example,
> which forces the transaction to be commited.
There's no explicit way to do this. However you can achieve this by
adding blocking activity, like
<wait><for>'PT1S'</for></wait>
>
>
> 2. Is the transaction XA ? Is it possible to add some custom JMS adapter,
> which uses the same tx for example ?
Yes, transactions can be XA. But ODE code does begin transaction for
each incoming exchange:
src/main/java/org/apache/ode/axis2/ODEService.java
public void onAxisMessageExchange(MessageContext msgContext,
MessageContext outMsgContext, SOAPFactory soapFactory)
throws AxisFault {
boolean success = true;
MyRoleMessageExchange odeMex = null;
Future responseFuture = null;
try {
_txManager.begin();
if (__log.isDebugEnabled()) __log.debug("Starting transaction.");
So I think this won't connect to existing JMS transaction. Neither for
JBI distro.
>
>
> I like this tx approach. I think one big transaction is harder to manage
> because of calling webservices ... Therefore, commiting on each wait or
> receive is OK.
Yes, this has bright sides too.
>
> Thank you very much.
> Raphaël
>
>
>
> 2010/4/20 Rafal Rusin <[email protected]>
>
>> Hello,
>>
>> 2010/4/19 Raphaël Delaporte <[email protected]>:
>> > Hi all,
>> >
>> > I'd like to know how transactions are used in the ODE engine.
>> >
>> > I know how it works in Oracle BPEL (TX are created and commited on
>> > dehydration activity, like Receive, Wait, OnMessage, etc...)
>> > But how does it work for ODE ?
>> >
>> > For instance, if I have an onMessage activity, is a new TX started when I
>> > received the callback ?
>> > And if so, when is it commited ?
>> >
>> > Thanks a lot for your help !
>>
>> ODE has two layers for transactions. First is for transport and second
>> for state transitions (so called JOBs).
>> When you invoke request to ODE, first layer stores MEX (message exchange)
>> to
>> DB and registers persistent JOB for processing. That's 1st TX.
>> Then this job is executed in state transitions layer and calculates
>> response - 2nd TX.
>> Next, such response is passed to transport layer and response is sent
>> back - 3rd TX.
>>
>> State transition transaction (JOB) is executed until blocking activity
>> is encountered (such as WAIT or RECEIVE or 2 way INVOKE).
>> So if you have:
>> <receive>
>> <assign>
>> <assign>
>> <invoke>
>>
>> It will execute in one transaction until INVOKE (INVOKE_RESPONSE will
>> be next transaction).
>>
>> I'm not quite convinced to such approach (the other approach is to
>> have one big transaction), but that's what we have now.
>>
>> Regards,
>> --
>> Rafał Rusin
>> http://rrusin.blogspot.com
>> http://www.touk.pl
>> http://top.touk.pl
>>
>
Regards,
--
Rafał Rusin
http://rrusin.blogspot.com
http://www.touk.pl
http://top.touk.pl
