Assaf, I would like to here from Maciej on what he sees the engine doing with the PartnerRoleMessageExchange.replyAsync() hint. Based on the API sequence diagrams I'm not sure I see how an ODE engine that asks a container for a thread, fits into the transaction patterns.
Lance On 6/2/06, Assaf Arkin <[EMAIL PROTECTED]> wrote:
On 6/2/06, Lance Waterman <[EMAIL PROTECTED]> wrote: > The synchronous API is easier to code for, so the default option if > > you're writing a lot of code. You can always optimize it better. But > > when you're designing a process you don't have that level of control > > to optimize it later, so the engine needs to decide. And it needs to > > consider management and performance. > > > > Separating a limited pool of process engine threads that only block > > for local resources (CPU, memory, database) > > > I was under the impression that the ODE engine would not be managing any > thread resources. When it comes to things like performance, scalability I want to have a level of control over the process engine so I can configure it for best results. Code wise, you might have an app server that owns all the threads, lets the ODE engine use some of these, allocates others to the bus. But when it comes to managing, I'm looking at that slice of the picture that I easily identify as "process engine". Everything in that process engine slice needs to play along nicely. If the app server does new Thread() and then the ODE decides to block for five minutes, then the ODE code is not doing a good job at helping the process engine slice manage its threads. Assaf
