[Design of JBoss jBPM] - Re: Concurrency in jBPM4
by roschmel
Hi Tom,
thanks for your answer....
Unfortunately - based on my knowledge - only the Thread based JobExecutor handles the exclusive Flag but not the enterprise deployment JobListenerBean. So here would the idea which we are working on would fit in. We could use a JBossCache for managing the exclusive locks for jobs. This would mean, that you also have to do the signals using jobs because it would be the only chance the get them - in a way - synchronized.
Currently when you are using async=true in an enterprise deployment you get the transaction demarcation as you desribed but just imagine following situation:
If I have a process 1 going to node A with async=true and going to node B with async=true (after a fork) then both JMS messages will be commited to the queue to the same time and if you have a fast enought server it will execute both in parallel and you will again get a StaleObject in one of them.
So If you want a lot of transaction demarcation you bring yourself in a situation where you increase the chance of StaleObject and therefore for rollback dramatically.
This is why we did not use async=true for transaction demarcation but we are using BMT and built an ActionHandler that we call SavePoint to commit a running transaction but keeping the Session and the JbpmContext open. This is possible with a little configuration work and one dirty code trick in the ActionHandler to handle the autoSaveInstances.
One other comment:
anonymous wrote : for each potential failure of non transactional resources you need to decide : either the process continues or the process execution rolls back till the last committed point of execution.
This works well for problems in the external resource - of course you can control this quite well. But if pull the plug right after the non transacted resource did its work sucessfully or if you cannot persist the process itself due to any database failure than you must know in a post mortem view, how long the process ran and where it crashed exactly to have the chance to bring the process back to a "normal" running condition.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4208071#4208071
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4208071
17 years, 2 months
Re: jbpm-3.2.5.SP
by Alejandro Guizar
Here is the spreadsheet with my checklist. Fortunately most issues are
covered by a test case in the jBPM codebase. A few others are specific
to the SOA-P environment or were rejected.
-Alejandro
El vie, 06-02-2009 a las 15:41 +0000, trevor kirby escribió:
> Because of the impact this is having on the schedules we have a limited
> time to confirm that 3.2.5 is compatible enough for our purposes.
> I've been told the cutoff date is Tuesday, after that we will have to
> fall back on 3.2.2 with backported fixes for this release. So we need to
> push to eliminate this list.
> The lack of examples prevents us testing 5 of them, Thomas can you tell
> us if your unit tests exercise those.
>
> I've also sent the list of jiras to QE so they can tell us if any can be
> eliminated.
>
> Trev
17 years, 2 months
Re: jbpm-3.2.5.SP
by Alejandro Guizar
Here is the spreadsheet with my checklist. Fortunately most issues are
covered by a test case in the jBPM codebase. A few others are specific
to the SOA-P environment or were rejected.
-Alejandro
El vie, 06-02-2009 a las 15:41 +0000, trevor kirby escribió:
> Because of the impact this is having on the schedules we have a limited
> time to confirm that 3.2.5 is compatible enough for our purposes.
> I've been told the cutoff date is Tuesday, after that we will have to
> fall back on 3.2.2 with backported fixes for this release. So we need to
> push to eliminate this list.
> The lack of examples prevents us testing 5 of them, Thomas can you tell
> us if your unit tests exercise those.
>
> I've also sent the list of jiras to QE so they can tell us if any can be
> eliminated.
>
> Trev
17 years, 2 months
Re: jbpm-3.2.5.SP
by Alejandro Guizar
I'm currently working through the list, finding the JBPM jiras that
correspond to the SOA jiras and verifying the presence of either a unit
test or a resolution applied to a specific class or document. I'm making
good progress so far. I will send you all an updated spreadsheet soon.
-Alejandro
El vie, 06-02-2009 a las 15:41 +0000, trevor kirby escribió:
> Because of the impact this is having on the schedules we have a limited
> time to confirm that 3.2.5 is compatible enough for our purposes.
> I've been told the cutoff date is Tuesday, after that we will have to
> fall back on 3.2.2 with backported fixes for this release. So we need to
> push to eliminate this list.
> The lack of examples prevents us testing 5 of them, Thomas can you tell
> us if your unit tests exercise those.
>
> I've also sent the list of jiras to QE so they can tell us if any can be
> eliminated.
>
> Trev
17 years, 2 months
[Design of JBoss jBPM] - Re: Concurrency in jBPM4
by tom.baeyens＠jboss.com
"roschmel" wrote : So in an ideal world you would exactly know where the process execution has crashed. This would mean committing every little step - but this is not really cool stuff.....
|
this is what we call a transactional script.
this is where jpdl is exactly suited for. see async="true". you can have the commit after every step.
"roschmel" wrote : So its first about knowing where the process have crashed - therefore you need logging information - just another topic I am currently discussing in the user forum.
|
no logging information is irrelevant. you need to map how you want java exceptions to affect the progress of your process.
for each potential failure of non transactional resources you need to decide : either the process continues or the process execution rolls back till the last committed point of execution.
"roschmel" wrote :
| And its about minimizing the chance, that a jBPM Transaction is getting rolled back. It is espacially about not considering a rollback as "a normal path of execution" - a rollback is for really bad things happended and not per design. So I think SOSE and retrying as a designed path of execution is simply wrong.
|
then i think you didn't get it yet.
"roschmel" wrote :
| What I would expect:
| If I have a process 1 waiting in state-A and waiting in state-B for the callback from an external system and both of them sending me the signal at the same time, I expect to have them executed just one after the other and I do not expect getting exception and letting the engine doing things twice.
|
this makes sense ! i didn't think if this use case yet.
should be really simple to get this one going. as we already have the exclusive job execution. that means that you can mark async messages or timers as being exclusive.
first, you have to make sure that all the progress in the process is made by the job executor. this would be possible to use the async command service. then you need to make sure that the async command service would set the exclusive flag to true.
then you need to make sure that all other jobs that are created in this process also set this exclusive flag to true.
good point!
we have all the infrastructure in place to make sure that we also cover this use case. i'll keep that in mind and hopefully this is fully documented by jbpm 4.0.0.GA
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207774#4207774
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4207774
17 years, 2 months
[Design of JBoss jBPM] - blobs, clobs, text and bytes
by tom.baeyens＠jboss.com
I'm adding binary process attachments to jbpm 4. I'm seeing things we need to improve relative to jbpm 3. I'm seeing new possibilities. But I don't see clearly the final solution yet. So please help fill my gaps:
1) chopping or blobs as the default strategy ?
* jBPM 3's capability to chop a blob into discrete sized chops and store a list of those chops turned out to be very portable
* i thought that oracle was one of the most difficult db's with respect to plain BLOBs. But currently in jBPM 4 this seems to work ok.
So the first question is: should we keep the chops as our default solution? Or can we rely on our own QA now and give the BLOB's another try ?
I already build a Lob (Large OBject) hibernate entity that can store a java.lang.String or a byte array in various ways (configurable). Then the handling of blobs and clobs becomes kind of configurable in one central location instead of spread out over the whole jbpm domain model.
2) Another aspect is the large text columns.
Here and there in the process definition datamodel and in the runtime datamodel, there are text columns. Typically string is fine. But for some DB's this is limited to 4K (was it ORA or DB2?). So we ended up truncating those strings.
Every string property that is potentially longer then 255 could a reference to such a Clob entity.
3) The third aspect is process definition vs runtime blobs. Process attachments need a blob, and storage of serialized objects also need a blob. Process attachments need to be cached in hibernate's second level cache. While process variables cannot be cached.
So this doesn't really match with the configurable Blob and Clob approach that i was buiding out. As hibernate cannot make a distinction between the process definition Blobs and the variable Blobs.
All input appreciated : extra requirements, desired improvements, silver bullet solutions,...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207739#4207739
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4207739
17 years, 2 months
[Design of JBoss jBPM] - Re: Concurrency in jBPM4
by roschmel
Hi,
let my try to explain my thoughts in short:
1) A lot of external system cannot be rolled back (WebService Calls, Legacy Systems...).
2) To make it worse, there are also a lot of system where a retry causes major issues (think about a Bank Transfer - doing it twice may not be good choice)
So in an ideal world you would exactly know where the process execution has crashed. This would mean committing every little step - but this is not really cool stuff.....
So its first about knowing where the process have crashed - therefore you need logging information - just another topic I am currently discussing in the user forum.
And its about minimizing the chance, that a jBPM Transaction is getting rolled back. It is espacially about not considering a rollback as "a normal path of execution" - a rollback is for really bad things happended and not per design. So I think SOSE and retrying as a designed path of execution is simply wrong.
What I would expect:
If I have a process 1 waiting in state-A and waiting in state-B for the callback from an external system and both of them sending me the signal at the same time, I expect to have them executed just one after the other and I do not expect getting exception and letting the engine doing things twice.
We are currently working on a pessimistic locking feature for this situation. But there are two major issues with it:
1) You have to find out what the shared resource is based on the command you get (and its most of the time the parents- parents- ... processinstance)
2) We are doing it in the CommandService EJB and because its a synchronous method call we have to block the thread until we get the look
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207712#4207712
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4207712
17 years, 2 months
