I've started looking at the DbError issue and reproduced it. Digging deeper
it seems it's caused by a lock timeout in Derby on the
OPENJPA_SEQUENCE_TABLE when ODE tries to create a record for the new
deployed process. Here is an excerpt from the logs:
DEBUG - GeronimoLog.debug(66) | Creating process DAO for {
http://tuscany.apache.org/implementation/bpel/example/helloworld}HelloWorld-1(guid=hqejbhcnphr3beiwcxrx88)
DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
DEBUG - GeronimoLog.debug(66) | prepareStmt: SELECT t0.ID, t0.GUID,
t0.PROCESS_ID, t0.PROCESS_TYPE, t0.VERSION FROM ODE_PROCESS t0 WHERE
(t0.PROCESS_ID = ?)
DEBUG - GeronimoLog.debug(66) | bound (1,{
http://tuscany.apache.org/implementation/bpel/example/helloworld}HelloWorld-1
)
DEBUG - GeronimoLog.debug(66) | close
DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
DEBUG - GeronimoLog.debug(66) | prepareStmt: SELECT SEQUENCE_VALUE FROM
OPENJPA_SEQUENCE_TABLE WHERE ID = ? FOR UPDATE WITH RR
DEBUG - GeronimoLog.debug(66) | bound (1,0)
DEBUG - GeronimoLog.debug(66) | close
DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
DEBUG - GeronimoLog.debug(66) | prepareStmt: INSERT INTO
OPENJPA_SEQUENCE_TABLE (ID, SEQUENCE_VALUE) VALUES (?, ?)
DEBUG - GeronimoLog.debug(66) | bound (2,1) (1,0)
DEBUG - GeronimoLog.debug(66) | close
DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
DEBUG - GeronimoLog.debug(66) | prepareStmt: SELECT SEQUENCE_VALUE FROM
OPENJPA_SEQUENCE_TABLE WHERE ID = ? FOR UPDATE WITH RR
DEBUG - GeronimoLog.debug(66) | bound (1,0)
WARN - GeronimoLog.warn(96) | connectionErrorOccurred called with null
java.sql.SQLException: A lock could not be obtained within the time
requested
Right now I really have no clue why this is happening, there's no reason why
a lock would get stuck on the OpenJPA sequence table. I have to dig deeper
but it's getting late, I'll try to find more time during the week-end or
Monday.
Cheers,
Matthieu
On Fri, May 30, 2008 at 1:42 PM, Mike Edwards <
[EMAIL PROTECTED]> wrote:
>
>
> -------- Original Message --------
> Subject: Re: SCA BPEL - Problems with ODE - Help requested
> Date: Fri, 30 May 2008 17:51:12 +0100
> From: Mike Edwards <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> References: <[EMAIL PROTECTED]> <
> [EMAIL PROTECTED]>
>
> Matthieu Riou wrote:
>
>> On Thu, May 29, 2008 at 11:41 AM, Mike Edwards <
>> [EMAIL PROTECTED]> wrote:
>>
>> Folks,
>>>
>>> I've run into problems with the SCA BPEL implementation and the way it
>>> interacts with the ODE engine - and I need help from some ODE experts,
>>> please.
>>>
>>> OK, the SCA code is using the ODE engine in an embedded mode - and the
>>> Tuscany code is trying to supply all the information and interfaces for
>>> each
>>> BPEL process to the ODE Engine - and in particular it aims to bypass the
>>> ODE
>>> database store so far as the BPEL process and its configuration are
>>> concerned.
>>>
>>> So - Tuscany now has its own version of the ProcessConfImpl (I sent a
>>> version of this out in a previous email). One thing I discovered is that
>>> it
>>> is necessary for the Tuscany ProcessConfImpl to return "true" to the
>>> isTransient() method. Otherwise, the ODE engine seems to try to find
>>> information about the process in the database with nasty consequences
>>> (failed transactions).
>>>
>>>
>> Normally that shouldn't be a problem. Transient tells ODE to execute the
>> process in memory but that only applies to short living processes, for
>> most
>> scenarios you'll want to have persistent executions. So we should try to
>> see
>> why these transactions fail.
>>
>>
>> HOWEVER, this has a side effect that is both curious and problematic.
>>>
>>> Using the ODE ProcessConfImpl (and by implication the database store for
>>> the process itself), for a trivial "Hello World" BPEL process, when the
>>> "hello" operation is invoked on the BPEL process, the ODE engine returns
>>> the
>>> result message as a "DeferredElementNSImpl" class with the name
>>> "TestPart" -
>>> which on inspection contains a child element "message" containing the
>>> expected "Hello World" string.
>>> (I attach the relevant part of the WSDL at the bottom)
>>>
>>>
>>> When we switch to using the Tuscany ProcessConfImpl - with its
>>> "transient"
>>> setting, when we invoke the same process, we get back a different type of
>>> object - an "ElementImpl" named "TestPart". This contains an
>>> ElementNSImpl
>>> object named "hello" containing a TextImpl child holding "Hello World".
>>> This
>>> structural layout is clearly different to the previous case - and is
>>> wrong -
>>> it isn't what is expected.
>>>
>>> Can anyone explain the difference in the two cases? Any assistance
>>> gratefully received.
>>>
>>>
>> I don't see what could create this difference. The deferred element vs.
>> normal element is nothing to worry about, it's just that the structure has
>> already been traversed in one case because of the storage different, but
>> the
>> content itself should be identical. Usually the switch from transient to
>> persistent doesn't bring that kind of differences but there's nothing I
>> can
>> think of off the top of my head that could create this behavior. The
>> structural difference kind of reminds the difference between rpc and
>> document style part wrappers but that shouldn't show here.
>>
>> So I'd like to reproduce this and see what's going wrong. Is all your code
>> committed? Which test case are you using?
>>
>> Thanks,
>> Matthieu
>>
>
> Matthieu,
>
> Thanks for responding - let me try and pick my way through it for you:
>
> 1) All the code is committed and in the current Tuscany SVN.
>
> 2) The runtime code that is relevant is all in the implementation-bpel-ode
> module
>
> 3) There are 3 sets of test/samples you can use to try things out:
>
> a) In Samples - helloworld-bpel and helloworld-bpel-ws
> b) In Itest - there are 4 Itests under BPEL - helloworld
> - helloworld-reference
> - helloworld-ws
> - ping-pong
>
> I tend to use the 2 samples. The second one uses web services and catches
> the problems with the
> data format returned by the BPEL process, for example. (You get an
> exception in the databinding code
> when it tries to transform it)
>
>
> Now, I've fixed up the code in implementation-bpel-ode so that it works -
> so the problems are all
> masked. But some simple commenting and uncommenting of lines of code can
> reproduce all the problems.
>
> The 2 main classes to deal with are:
>
> - EmbeddedODEServer
> - TuscanyProcessConfImpl
>
>
> Currently, EmbeddedODEServer is set up to use the ODE Store and Persisted
> BPEL Processes - the trick
> I've done is that the code itself WRITES the deploy.xml file on the fly -
> so that the programmer
> does not need to write it. This is handled by the BPELODEDeployFile class.
>
> To change things, all you need to do is to go to the deploy(....) method in
> EmbeddedOdeServer. You
> will find 2 blocks of code inside a try{} block - one for using the ODE
> Store, the other for using
> the Tuscany stuff without the store. Simply comment out one an uncomment
> the other to flip between
> them.
>
> Only one other thing needs changing to work through all the problems - and
> that is the response to
> the isTransient() method of the TuscanyProcessConfImpl - currently it's set
> to "true" - simply flip
> it to return "false" to see the other behaviour.
>
>
> One significant thing I discovered is that there is a "memory effect" in
> the database. IF the
> database has been used ONCE by the ODE Store code then if the code is run
> afterwards in "non Store"
> mode, it works ok, with no transaction errors. The transaction errors only
> occur with a "virgin"
> database that has never been used by the Store code. If that ain't
> confusing, nothing is...
>
> Note - running the Samples and Itests above using mvn usually cleans out
> the DB - I've been able to
> preserve the DB when running from Eclipse.
>
> When getting the transaction problem, my tracing showed that is happening
> in:
>
> BpelProcess$HydrationLatch.doHydrate() line 755
> "DbError"
> "Unable to Commit"
>
>
> Yours, Mike.
>
>
