Currently the JBI IL starts an ODE server
BpelServer.start()
The BpelServer pulls all ProcessDAO's out of the DB and loads into memory
those marked with ProcessDAO.isActive().
The IL iterates over it's list of pids that comprise a service unit and
calls:
BpelServer.activate(pid,sticky)
The BpelServer will pull the ProcessDAO out of the DB and loads it into
memory
As far as I can tell the current implementation does not support the concept
of process "suspend"/"resume"
from ProcessAndInstanceManagementImpl.
public ProcessInfoDocument activate(QName pid) {
// TODO: Figure out how to deal with activation/retirement.
return genProcessInfoDocument(pid, ProcessInfoCustomizer.NONE );
}
If the implementation is enhanced to support "suspend"/"resume" then I can
see the above use case being implemented as
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
On 8/17/06, Assaf Arkin <[EMAIL PROTECTED]> wrote:
I think this has to do with JBI, where you delegate lifecycle management
to
the container by exposing an API it can use to start/stop/shutdown
individual service units.
Assaf
On 8/17/06, Lance Waterman < [EMAIL PROTECTED]> wrote:
>
> From the IL/client's perspective, it seems like control over when a
> process
> is "suspended" is the correct level of management. Whether a process is
> loaded into memory or not seems like an engine detail that the IL/client
> shouldn't really care about - but perhaps I'm missing a nuance in this.
>
> Lance
>
>
> On 8/17/06, Maciej Szefler < [EMAIL PROTECTED]> wrote:
> >
> > you missed one:
> > a process can be deployed, but "suspended": this allows you to prevent
> > work being performed on behalf of any of the process instances without
> > undeploying it.
> >
> > -mbs
> > On Thu, 2006-08-17 at 12:16 -0700, Assaf Arkin wrote:
> > > also confused by terminology here.
> > >
> > > Specific process instance can be in memory doing some work, or in
the
> > > database.
> > > Specific process instance can be suspended (not processing events
even
> > > if they arrived)/resumed.
> > > Process definition can be deployed or not.
> > > Deployed process definition can be used to instantiate new processes
> > > or not.
> > >
> > > What would be the best way to name those?
> > >
> > > Assaf
> >
> >
>
>
--
CTO, Intalio
http://www.intalio.com
