On Tue, Apr 29, 2008 at 5:52 AM, Thomas Steinmetz <[EMAIL PROTECTED]>
wrote:
>
> Hi all,
>
> since that didn't work, I'm trying another, rather ineffiecent approach.
> Of
> course I encountered some problems again ( :( ) and I don't have a clue,
> what's going wrong.
>
>
> When creating a BpelRuntimeContextImpl I inject an object (RUNNER), that
> keeps this BpelRuntimeContextImpl alive for some time.
>
> public class RUNNER extends BpelJacobRunnable
> {
> private static final long serialVersionUID = 555136346635L;
>
>
> public RUNNER()
> {
>
> }
>
> public void run() {
> if (getBpelRuntimeContext().getVPU().counter < 50)
> {
> instance(RUNNER.this);
> }
> else
> {
> instance(new WAITER());
> }
> }
>
> }
>
> If nothings seems to happen at that instance (50 conescutive executions of
> that RUNNER object), a WAITER object gets injected. So, whenever the
> execution of one instance stopps at a certain point in the process
> (receive,
> wait and so on) one WAITER object is created.
>
> public class WAITER extends BpelJacobRunnable
> {
> private static final long serialVersionUID = 65661L;
>
> public void run() {
> final TimerResponseChannel timerChannel =
> newChannel(TimerResponseChannel.class);
> Date dueDate = new Date((System.currentTimeMillis() +
> 1000));
> getBpelRuntimeContext().registerTimer(timerChannel, dueDate);
>
> object(false, new TimerResponseChannelListener(timerChannel){
> private static final long serialVersionUID =
> 3120518305645437327L;
>
> public void onTimeout() {
> }
>
> public void onCancel() {
> }
> });
> }
>
> }
>
> This object should do the same as a wait activity (as it waits for 1
> second
> until the timer fires and restarts a new BpelRuntimeContextImpl).
>
> Now there seem to be some kind of problem (see pictures below, got it when
> executing the MagicSession example).
> I just don't see where these errors come from, as I am effectively doing
> the
> same as some additional wait activities in the process itself would do.
>
> Or is there a conflict with having (for example) one pick activity that
> waits for an incoming message and one WAITER object that waits for 1
> second
> at the same time? So that there are two WorkingEvents that try to start a
> new BpelRuntimeContextImpl, although an older version is still running?
>
> I hope someone knows, where these errors come from.
>
I would guess it's a transaction boundaries problem again. When the timer
fires it starts a new transaction, reloading the runtime context and the
Jacob state for the database. It seems that at this point the timer channel
can't be found which probably means that the previous transaction hasn't
been committed yet as it should.
Matthieu
>
> Greetings,
> Thomas
>
> http://www.nabble.com/file/p16959747/pic1.gif
> --
> View this message in context:
> http://www.nabble.com/Encountered-a-problem-while-modifying-the-runtime-tp16824336p16959747.html
> Sent from the Apache Ode Dev mailing list archive at Nabble.com.
>
>
