Hi Rafal,
I create a simple process to test an onAlarm timeout for an entire bpel
process. My process went something like this:
<process>
...
<sequence>
<receive .../>
<assign .../>
<validate .../>
<reply .../>
<sequence>
<eventHandler>
<onAlarm>
<for>'PT10S'</for>
<scope>
<variables .../>
<assign .../>
<reply faultName="..." .../>
</scope>
</onAlarm>
</eventHandler>
</process>
I set a breakpoint in validate to cause it to time out. For a while I
couldn't work out why it never timed out, but then after some debugging I
realised that the scheduling of the timeout is never committed (see
SimpleScheduler#addTodoOnCommit) and this jogged my memory about your post.
I guess my example is contrived since who would use bpel without calling a
web service but it is an interesting side-effect of the commit policy don't
you think?
-
Regards,
Terry
On 20 April 2010 08:08, Rafal Rusin <[email protected]> wrote:
> 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
>
