Apologies, but it seems my emails addressing these points had suffered a outbox queue blockage of some sort. You should now have received email from me dated Thursday 6:47pm. and 7:01pm EST.
-mbs On Fri, 2006-06-02 at 12:34 -0600, Lance Waterman wrote: > 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 > >
