[ https://jira.jboss.org/jira/browse/JBPM-1423?page=com.atlassian.jira.plug... ] Tom Baeyens updated JBPM-1423: ------------------------------ Description: Identify the supported deployment environments and the corresponding configurations. This basically will come down to transaction configurations in pvm, hibernate, spring, ejb and the likes. Configurations: * pvm * hibernate * ejb Controlling transactions: * Hibernate transaction programmatic * Direct JDBC connection programmatic * JTA UserTransaction programmatic (== BMT?) * CMT through EJB deployment descriptors Also take given JDBC connections into account was: Identify the supported deployment environments and the corresponding configurations. This basically will come down to transaction configurations in pvm, hibernate, spring, ejb and the likes. Configurations: * pvm * hibernate * ejb Controlling transactions: * Hibernate transaction programmatic * Direct JDBC connection programmatic * JTA UserTransaction programmatic (== BMT?) * CMT through EJB deployment descriptors -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBPM-1423?page=com.atlassian.jira.plug... ] Tom Baeyens commented on JBPM-1423: ----------------------------------- We have to look from a user application perspective. The user might want to control transaction in its own application. In that case PVM should be able to hook into that very transaction. Or the user might want to use the pvm for transaction management. In which case the user must be able to obtain the declared transactional resources or to add new transactional resources. We have to identify all the supported combinations of transaction management from the user (client project) perspective. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBPM-1423?page=com.atlassian.jira.plug... ] Tom Baeyens commented on JBPM-1423: ----------------------------------- standard java =========== 1) environment block controls the jdbc transaction through hibernate. hibernate being one resource in the standard transaction. 2) user controls the jdbc transaction with hibernate and environment block has got to participate in that same tx. Here, the tx will have a bigger scope then the environment block. So special care should be taken to verify all usages of transaction-end-listeners (like synchronisations) 3) user controls the transaction with spring and environment block has got to participate in that same tx. Same comment: tx scope is bigger then environment block scope. can we find a way so that the API tests are all executed in each of these 3 deployment configurations ? enterprise java ============ In enterprise Java, we can always assume that the transaction is controlled by JTA and that the transaction has a bigger scope then the environment block. The most common case will be CMT controls the transaction and pvm is addressed through the ExecutionService local SLSB osgi ==== testing only one of the tx configurations in osgi will be sufficient. To create a bundle out of PVM, the -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBPM-1423?page=com.atlassian.jira.plug... ] Tom Baeyens commented on JBPM-1423: ----------------------------------- @Miguel, The execution modes are basically split into 2 categories: service and client. Service execution modes means that there is a XxxService being used. Translating the method into a command and then the command is executed behind a set of interceptors and inside an environment block. These are the persistent use cases in standard java and enterprise java. Client execution mode means that the process is executed by invoking methods on the java object model (ClientExecution) directly. This is used for in-memory execution. Because of the cross cutting concerns (persistence/transactions and so on), these API's were differentiated. The client execution mode is used to test the functional behaviour of the PVM features in the PVM test suite. Each time we develop a new feature, the client execution mode is used to develop it. Once that is done, we add persistence into the mix. Now, coming back to your point: For the service execution modes, there are a lot of configurations thinkable. But all of those should be used with the same API. So for all the service (read persistent) execution modes, we should make sure that these are tested (at least in the continuous integration) in all the supported configurations. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBPM-1423?page=com.atlassian.jira.plug... ] Tom Baeyens resolved JBPM-1423. ------------------------------- Resolution: Done -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira