Maciej, My only point is that "BpelServer.start(pid,sticky)" seems to be doing the same thing as ...
suspend/resume is a user wishing to prevent the process from being active until such time as the user decides to change his mind
within a startup context. I'm not going to belabor the point and will incorporate the distinction ( as you have defined it ) within the deploy design. Lance On 8/18/06, Maciej Szefler <[EMAIL PROTECTED]> wrote:
Lance, The concern is integration into life cycle mechanisms of the enclosing infrastructure. In the JBI example, the processing on behalf of a process should not begin until JBI decides to "start" the service unit that contains that process. Using the PMAPI in this case is not appropriate -- the use case for a pmapi suspend/resume is a user wishing to prevent the process from being active until such time as the user decides to change his mind. The use-case for "start" is an orderly startup of the engine and IL. -maciej On Thu, 2006-08-17 at 16:11 -0600, Lance Waterman wrote: > The JBI IL starts an ODE server > > BpelServer.start() > > The BpelServer pulls all ProcessDAO's out of the DB and loads all into > memory. The ProcessDAO has a status flag which indicates > "suspended"/"started". Only "started" processes can accept message > events from the ODE router. Note: by default JBI deployed processes > are loaded into memory in a "suspended" state. > > The IL iterates over it's list of pids that comprise a service unit > and calls: > > BpelServer.getManagementFacade().resume(pid,sticky) > > The ProcessDAO status flag is set to "started" and the process is now > available to accept message events from the ODE router. > > Is the concern here that loading all JBI ProcessDAO's into memory is a > lot of overhead? > > Lance > >
