this is afaik actually a hibernate issue and depends on your database and the way primary keys are generated.
As you probably know, folks usually use the database for key generation because it avoids any possible contention across multiple threads, multiple classloaders (if a singleton is used to address thread synchronization), and multiple servers (if clustering). So...
It sounds like you won't get what you're asking for, so maybe back up: why do you need the process ID at that point in time? Maybe there's a different way to do it?
Another possibility, which I hesitate to mention, is that you might somehow coerce jBPM+Hibernate to write a "stub" process instance early, with just the id and little else, and fill in the rest later. I have no idea what the ripple from this would be - it seems quite dangerous, and would probably require a lot of code reconciling whenever you want to adopt a new version of jBPM.
(I'm a newbie - I may not know what I'm talking about!)
thanks for your replies.
@estaub: The ID of the running process instance will help me observe some Quality of Service (QoS) performance behaviour at the time web service are being consumed therefore during execution of the bussiness process.
Any other suggestion please?
within an action.
Or do you use an external application?
I'm using, how can i say it: the jbpm-bpel Engine to orchestrate my BPEL processes. In my case it's not an action like you are mining.
i have tried it allready:
ExecutionContext exeContext = ExecutionContext.currentExecutionContext();
and calling the following methods raise a NullPointerException
long procID = exeContext.getProcessInstance().getId(); long procID = exeContext.getContextInstance().getProcessInstance().getId();
Can you add your own process "instance ID" variable containing an externally-assigned ID that you can track?