Hide Forgot
currently, DML statements related to jbpm-bam functionality are made synchroneously within the scope of the same transaction as core jbpm5 functionality (processInstance, SessionInfo, WorkingItemInfo, task, etc) load tests have revealed that, for instance, an invocation to 'startProcess' with jbpm-bam disabled returns about 2.5 - 3 times faster than when the jbpm-bam is enabled. recommend that an 'AsyncWorkingMemoryLogger' be built such that jbpm-bam logging invocations be sent to a JMS provider rather than immediately writing to the jbpm-bam relational database. Subsequently, a jbpm-bam MessageConsumer would also be created that consumes these jbpm-bam logging invocations in batch. Once a configurable batch size is reached, the MessageConsumer would write to the jbpm-bam database using optimized SQL batch insert/update statements. sorry, i don't yet have a working implementation of this.
(In reply to comment #0) > load tests have revealed that, for instance, an invocation to 'startProcess' > with jbpm-bam disabled returns about 2.5 - 3 times faster than when the > jbpm-bam is enabled. It would be useful to know if a call to startProcess with an additional load of sending like 6 JMS messages (in the same transaction) would be faster than just persisting the log events reusing the runtime persistence entity manager (which is just done in one commit, at the end of the transaction). As it would be a pity if this in the end would be slower ;)
Jeff, if we're doing this to improve performance, then it makes more sense to me not to use JMS/HornetQ. Why not just use "concurrent" java, so to speak? It does mean a lot more "gun" to "shoot yourself in the foot" with, but it will always be faster than the overhead time cost incurred by either the current implementation or JMS/HornetQ.
Marco, I think the concept of transaction might be critical here. We only want these events to be stored (so the messages to be sent) when the transaction is committed successfully. A transaction rollback should not save these events (not send the messages). You could do this with JMS, not sure you could do the same with concurrent java.