[JBoss jBPM] - JBPM and Managed Container Transactions
by trouby
Hey,
I am trying to make JBPM to work smoothly through EJB3 components with no success,
After invoking very simple methods through a stateless EJB3 such as:
| ProcessInstance pi = jbpmContext.loadProcessInstance(spmlTask.getWorkflowProcessId());
|
I'm getting errors such as:
| 23:13:38,858 ERROR [TimerImpl] Error invoking ejbTimeout: javax.ejb.EJBException: javax.persistence.TransactionRequiredException: Entity
| Manager must be access within a transaction
|
I assumed this is due to the fact that somewhere JBPM commits the transaction so invocations after that causes the exception,
I have followed section "7.1.3. Managed transactions" in the manual:
anonymous wrote :
| A stateless session facade in front of jBPM is a good practice. The easiest way on how to bind the jbpm transaction to the container transaction is to make sure that the hibernate configuration used by jbpm refers to an xa-datasource. So jbpm will have its own hibernate session, there will only be 1 jdbc connection and 1 transaction.
|
But setting it up is not clear enough, I tried to configure JBPM as follows:
hibernate.cfg.xml
| ...
|
| <property name="connection.datasource">java:/veloDatasource</property>
| <property name="transaction.factory_class">org.hibernate.transaction.JTATransactionFactory</property>
| <property name="transaction.manager_lookup_class">org.hibernate.transaction.JBossTransactionManagerLookup</property>
|
| ...
|
jbpm.cfg.xml
| <jbpm-context>
| <service name="persistence">
| <factory>
| <bean class="org.jbpm.persistence.db.DbPersistenceServiceFactory">
| <field name="isTransactionEnabled"><false/></field>
| </bean>
| </factory>
| </service>
| <service name="tx" factory="org.jbpm.tx.TxServiceFactory" />
|
| ...
|
where veloDataSource is defined in persistence.xml as follows
| <local-tx-datasource>
| <jndi-name>veloDatasource</jndi-name>
| <connection-url>jdbc:mysql://localhost:3306/velo</connection-url>
| <driver-class>com.mysql.jdbc.Driver</driver-class>
| <user-name>root</user-name>
| <password>password</password>
| </local-tx-datasource>
|
Seems like JBPM is not using the MC transaction and if I understand correctly, JBPM commits the transaction and that what causes the persistence unit to fail later on.,
Can anyone give me a hand how to proceed from here?
Man thanks,
Asaf.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191905#4191905
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191905
17 years, 5 months
[Microcontainer] - Re: Configuration deployments
by alesj
"charles.crouch(a)jboss.com" wrote :
| But we don't use this technique to configure/reconfigure the EJB Container itself do we?
|
No, I would expect EJB Container to be a bunch of MC beans,
hence configurable via MC based ManagedObject.
"charles.crouch(a)jboss.com" wrote :
| I thought that would be analogous to what David is trying to do?
|
Perhaps I didn't give the best example + missing some details. :-)
It was more about just using metadata and not making it into beans + not undeploying it.
But there is nothing preventing you to annotate your custom metadata
with ManagedObject annotations and then exposing them.
I guess some more MO impl details are needed,
e.g. InstanceClassFactory or ManagedObjectBuilder
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191901#4191901
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191901
17 years, 5 months
[Microcontainer] - Re: Configuration deployments
by charles.crouch＠jboss.com
"alesj" wrote : Sure, this is nothing abnormal.
| We do this all the time.
| e.g. EJB metadata --> JBossMetaData
| It eventually gets used by EJB container, helping create proper services/beans,
| but never gets undeployed, since there is nothing to undeploy.
|
But we don't use this technique to configure/reconfigure the EJB Container itself do we? I thought that would be analogous to what David is trying to do?
"david.lloyd(a)jboss.com" wrote : This would allow me to reconfigure services at runtime without having to introduce any hard API dependencies on the MC.
This sounds more like a configuration (i.e. metadata overrides, i.e. profile service issue) than a deployment shaped one.
David, if you've got the time, have you got an example of the original service deployment descriptor and an example change you would expect to see. This might help clarify if the profile service would help here or not.
Thanks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191893#4191893
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191893
17 years, 5 months
[JBoss Cache: Core Edition] - Jboss Cache rollback
by narek1w
I am working on using two Jboss Caches for my Web application. The first one is used by Hibernate as second level cache. The other is multipurpose cache for other objects (bean PojoCache ) .
I am having synchronization issues in case of exception. When I throw an exception the Hibernate transaction is being rollback, however the second cache contains invalid values that should be rollbacked.
My question is how to configure my for cache for rollback ( PojoCache ).
The application is bases on Spring 2.5 , Hibernate 3.3 , Jboss Cache 3.0 and Jboss AS 5.0.
Spring config :
<bean id="hibernateSessionFactory"
| class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
|
| <property name="dataSource" ref="dataSourceJndi" />
| <property name="hibernateProperties">
| <props>
| <prop key="hibernate.dialect">org.hibernate.dialect.PostgreSQLDialect
| </prop>
| <prop key="hibernate.hbm2ddl.auto">update</prop>
| <prop key="hibernate.show_sql">true</prop>
| <prop key="hibernate.format_sql">false</prop>
| <prop key="hibernate.transaction.factory_class">org.hibernate.transaction.JTATransactionFactory
| </prop>
|
| <prop key="hibernate.transaction.manager_lookup_class">
| org.hibernate.transaction.JBossTransactionManagerLookup</prop>
|
| <prop key="hibernate.cache.region.factory_class">
| org.hibernate.cache.jbc2.SharedJBossCacheRegionFactory</prop>
|
| <prop key="hibernate.cache.region.jbc2.cfg.shared">mvcc.xml</prop>
|
| <aop:aspectj-autoproxy />
|
| <bean id="transactionManager"
| class="org.springframework.transaction.jta.JtaTransactionManager">
| </bean>
|
| <tx:annotation-driven transaction-manager="transactionManager" />
|
|
Obtaining Cache
| MBeanServer server = MBeanServerLocator.locateJBoss();
| ObjectName on = new ObjectName("jboss.cache:service=Cache2");
| CacheJmxWrapperMBean cacheWrapper = (CacheJmxWrapperMBean) MBeanServerInvocationHandler
| .newProxyInstance(server, on, CacheJmxWrapperMBean.class, false);
| cache = cacheWrapper.getCache();
|
|
The database is rollbacked , but cache is updated with invalid values.
My method that I would like to rollback changes to cache:
| @Transactional(propagation = Propagation.REQUIRES_NEW)
| @Override
| public void add(Product p) {
| getHibernateTemplate().save(p);
|
| PojoCache pc = new PojoCache();
| pc.setId(p.getId());
| pc.setCounter(p.getCounter());
|
| cache.put(pc);
|
| PojoCache p2 = cache.get(-1);
| if (p2 == null) {
|
| PojoCache pc2 = new PojoCache();
| pc2.setId(-1);
| pc2.setCounter(1);
| cache.put(pc2);
| } else {
| p2.setCounter(p2.getCounter() + 1);
| cache.put(p2);
| }
|
| Date date = new Date();
| if (date.getTime() % 10 == 0) {
| throw new RuntimeException();
| }
|
Thanks,
Marek
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191891#4191891
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191891
17 years, 5 months
[Clustering/JBoss] - Re: Wierd issue with clustered nodes
by bstansberry＠jboss.com
This sounds like some sort of network problem. In particular
2008-02-21 08:35:11,784 WARN [org.jgroups.protocols.pbcast.GMS] failed to collect all ACKs (3) for view [172.17.65.39:40883|5] [172.17.65.39:40883, 172.17.66.39:35267, 172.17.67.39:39896, 172.17.64.39:52927] after 5000ms, missing ACKs from [172.17.65.39:40883, 172.17.66.39:35267, 172.17.6 .....
sounds like 172.17.65.39:40883 is not able to get a response from itself to its own message. The OS should copy a multicast back to an in-machine listener making it go out on the wire, so not receiving your own message is a sign that either:
1) There's a problem with the network interface being used.
2) The thread that delivers messages has gotten stuck. Getting a stack trace can help show if that has occurred.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191890#4191890
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191890
17 years, 5 months