[JBoss jBPM] - Dynamic Fork + External Async WS invocation + problem
by clandestino_bgd
Hi people, in short:
My Process:
Just after Start state, I have dynamic fork (Action Handler defined on Node, very similar to the one on wiki). In each child I have a Task node, on which event (task-create) I have an ActionHandler which invokes WS asynchronously, by passing taskInstanceId as parameter.
When WS finishes the operation, it invokes callback method which ends the task instance.
And the problem:
When I start the process instance, if I have a significant number of children, it happens that the 1st WS does the callback before all child tokens are generated, which results in NPE when I try to get task instance in callback method.
Ok, seems, that new tokens and created task instances are not persisted in DB, but only in memory and this is according to docs, but can I somehow change the default behavior and support the described scenario?
Or maybe somebody has an idea how to support "concurrent" WS invocations without explicitely call to each of them?
Retrying callback or WS timeout can fix the problem, but this is configurable on WS side, not JBPM.
Any idea, much appreciated.
best,
milan
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206146#4206146
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206146
16 years, 11 months
[JBoss Cache: Core Edition] - Re: very strange behaviour of jboss cache 1.4.1
by bstansberry@jboss.com
Yes, see comment I posted a half-hour or so ago on the other thread.
If you execute native queries, Hibernate has no way to know what changes you are making in the underlying database, and is forced to aggressively clear the cache to avoid leaving stale data.
Same thing applies if you do bulk updates -- i.e. update a bunch of entities that match a where clause -- since Hibernate doesn't know what entities match the where clause. So it is forced to remove all entities of the particular type from the cache.
If you query for the entities that match your where clause and then iterate over them making the update one by one, Hibernate knows what entity instance was changed and can update the cache for just that one instance. Of course if your where clause matches a lot of entities, it might be more performant to accept losing the cache contents and do the bulk update.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206134#4206134
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206134
16 years, 11 months