I have a standalone application A that invokes a webservice B deployed in jboss eap 6.2.3. the application in jboss uses a mysql datasource. This application integration is working very well.
I needed to webify the standalone application itself into a spring rest data jpa microservice
So I wrote a spring boot wrapper for that standalone application A. It runs in an embedded tomcat and invokes the aplpication B running in jboss.
I also ported some configurations logic from properties files into a embedded h2 database.
Now at places I am seeing this exception shown below for insert into the mysql by the application B inside jboss. My guess is what was a simple transaction earlier and working well has now become a 2 phase commit that sometimes fails.
How to prevent this?
Caused by: javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1177)
at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) [jboss-as-ejb3-7.3.3.Final-redhat-SNAPSHOT.jar:7.3.3.Final-redhat-SNAPSHOT]
... 67 more
Caused by: org.infinispan.CacheException: Could not prepare.
at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:70) [infinispan-core-5.2.7.Final-redhat-2.jar:5.2.7.Final-redhat-2]
at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165)
... 70 more
Caused by: javax.transaction.xa.XAException
at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:161) [infinispan-core-5.2.7.Final-redhat-2.jar:5.2.7.Final-redhat-2]
at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:123) [infinispan-core-5.2.7.Final-redhat-2.jar:5.2.7.Final-redhat-2]
at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68) [infinispan-core-5.2.7.Final-redhat-2.jar:5.2.7.Final-redhat-2]
... 75 more
Spring Boot has out-of-the-box support for JTA. When it runs in an environment where a JTA transaction manager is available, it uses that rather than creating a local transaction manager for your data store. If that's not what you want, you can disable jta support by adding spring.jta.enabled=false to your configuration.
Thanks for the answer.Will be useful in some scenarios.
However after posting I realised the flaw in the question.
standalone application A
webified application(even if a microservice runninging embeddedtomcat ) say A1
Both are actually just rest clients to rest services running in a webservice B deployed in jboss eap 6.2.3..
A and A1 might as well be replaced by just a simple human visitor visting from a browser the application B.
I dont think A or A1 can influence the transactions in any ways for B.
Right?
Anyways the problem was due to the closeness to B of the application A1.
The actual problem was related to a cluster event for the cluster in which B was deployed and triggering of it by A1. A bit complicated scenario. The only problem was that the insert was being attempted too soon before the cluster change event could even reach.
Related
After migrating from Wildfly-8.2.0 to Wildfly-16.0.0, my JEE application launched normally and
displayed expected data read from (PostgreSql) database, but neither of the (insert/update/delete)
operations is saving to database (with no exception fired) !
I redeployed the same application on the old version of Wildfly and (insert/update/delete) operations worked.
What was missing is to add the "eclipselink.jar" file in
"wildfly\modules\system\layers\base\org\eclipse\persistence\main"
and reference it as a "resource-root" in
"wildfly\modules\system\layers\base\org\eclipse\persistence\main\module.xml"
Unfortunatelly, no exception was fired describing the missing configuration of eclipselink!
I'm observing weird behavior for WebSphere 7.0.0.21:
Architecture:
Simple EJB bean with annotation #Local, #Remote Interfaces and transactional method marked as #Required
Standalone command line client that looks up remote "jta/usertransaction" and transactional EJB method. Client code starts user transaction, executes method and then tries to rollback it.
Expected behavior: (I see it on Jboss) rollback of DB transaction
Observed behavior: (On WAS 7.0.0.21) commit of DB transaction
I see that client transaction is changing from STATUS_NO_TRANSACTION(6) to STATUS_ACTIVE(0) and then again to STATUS_NO_TRANSACTION(6) after rollback.
I tried to Google it but didn't find any results
Any ideas on this scenario ? I'm pretty much ready to file the issue to IBM.
thanks,
UPDATE:
Finally after long wait and interactions with IBM support I got it resolved:
No problems with IBM JRE
For Sun/Oracle JRE it requires extra configuration for ORB e.g.
jndiProperties.put("java.naming.corba.orb", com.ibm.CORBA.iiop.ORB.init((String[])null, orbProperties));
and orb.properties from WAS or AppClient JRE is required to be provided as "orbProperties"
I have installed successfully Drools KIE-WB with MYSQL (in Tomcat), and I want to achieve the same goal with the dashbuilder.
My dashbuilder package is jbpm-dashbuilder-6.1.0-SNAPSHOT-tomcat-7. And I have tested two different options:
The first tested option is:
Executing the file in tomcat-7.0.50\webapps\dashbuilder\WEB-INF\etc\sql\1-create-mysql.sql. It creates some tables, but seems that something is missed, because this error appears when starting the server:
com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table 'dashboarddb.processinstancelog' doesn't exist
The second tested option is:
Change tomcat-7.0.50\webapps\dashbuilder\META-INF\context.xml to have the next datasource
<Resource name="jdbc/jbpm" auth="Container"
type="javax.sql.DataSource" username="drools-user" password="pass" driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://localhost:3306/dashboarddb?useUnicode=true&characterEncoding=UTF8"
maxActive="8"
/>
And in tomcat-7.0.50\webapps\dashbuilder\WEB-INF\etc\hibernate.cfg.xml I have added the next line:
<property name="hibernate.hbm2ddl.auto">update</property>
To force Hibernate to create all tables in MySQL. This almost work (create several tables) but an error appears:
com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry '1-title-Dashboards Showcase' for key 'PRIMARY'
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
...
And I have no idea how to fix it (because I have no information about what Hibernate is doing and creating).
I have no more ideas of how to install the dashboard using MySQL. Any clue about how to achieve it?
The two webapps (Kie-wb and jBPM dashboard) must share the same database since the jBPM dashboard feeds from the jBPM history-log (more details here https://github.com/droolsjbpm/jbpm-dashboard/tree/master/jbpm-dashboard-distributions/src/main/tomcat7).
So you first need to deploy and run kie-wb against a given data source. Let's say you named it "kie-wb". Once you have kie-wb running (tables created on DB) you can proceed deploying jbpm-dashboard, which must be configured to connect against the same "kie-wb" datasource.
DON'T enable auto ddl update as it's not recommended in production. You can either run the script 1-create-mysql.sql prior to the app. deployment or just let the app run it on start up (auto running the script it's actually done by the app itself if it doesn't detect some required tables).
If you follow the steps above everything should be working fine.
Otherwise, don't hesitate to ask again.
I've been working on a web application, deployed on Tomcat 7, which use EclipseLink JPA to handle the persistence layer.
Everything works fine in a test environment but we're having serious issues in the production environment due to a firewall cutting killing inactive connections. Basically if a connection is inactive for a while a firewall the sits between the Tomcat server and the DB server kill it, with the result of leaving "stale" connections in the pool.
The next time that connection is used the code never returns, until it gets a "Connection timed out" SQLException (full ex.getMessage() below).
EL Fine]: 2012-07-13
18:24:39.479--ServerSession(309463268)--Connection(69352859)--Thread(Thread[http-bio-8080-exec-5,5,main])--
MY QUERY REPLACED TO POST IT TO SO [EL Config]: 2012-07-13
18:40:10.229--ServerSession(309463268)--Connection(69352859)--Thread(Thread[http-bio-8080-exec-5,5,main])--disconnect
[EL Info]: 2012-07-13
18:40:10.23--UnitOfWork(1062365884)--Thread(Thread[http-bio-8080-exec-5,5,main])--Communication
failure detected when attempting to perform read query outside of a
transaction. Attempting to retry query. Error was: Exception
[EclipseLink-4002] (Eclipse Persistence Services -
2.3.0.v20110604-r9504): org.eclipse.persistence.exceptions.DatabaseException Internal
Exception: java.sql.SQLException: Eccezione IO: Connection timed out
I already tried several configuration in the persistence.xml, but since I have no access to the firewall configuration I had no luck with these methods. I also tried to use setCheckConnections()
ConnectionPool cp = ((JpaEntityManager)em).getServerSession().getDefaultConnectionPool();
cp.setCheckConnections();
cp.releaseConnection(cp.acquireConnection());
I managed to solve the issue in a test script using testOnBorrow, testWhileIdle and other features that are avalaible from DBCP Apache Commons. I'd like to know how to override the EclipseLink internal connection pool to use a custom connection pool so that I can provide an already configured pool, based on DBCP rather than just configuring the internal one using persistence.xml.
I know I should provide a SessionCustomizer, I'm uncertain which one is the correct pattern to use. Basically I would like to preserve the performance of DBCP in a JPA-like way.
I'm deploying on Tomcat 7, I know that if I switch to GF I won't have this problem, but for a matter of consistency with other webapp on the same server I'd prefere to stay on Tomcat.
What you want is definitely possible, but you might be hitting the limits of the "do it yourself" approach.
This is one of the more difficult things to explain, but there are effectively two ways to configure your EntityManagerFactory. The "do it yourself" approach and the "container" approach.
When you call Persistence.createEntityManagerFactory it eventually delegates to this method of the PersistenceProvider interface implemented by EclipseLink:
EntityManagerFactory createEntityManagerFactory(String emName, Map map)
The deal here is EclipseLink will then take it upon itself to do all the work, including its own connection creation and handling. This is the "do it yourself" approach. I don't know EclipseLink well enough to know if there is a way to feed it connections using this approach. After two days on Stackoverflow it doesn't seem like anyone else has that info either.
So here is why this "works in GF". When you let the container create the EntityManagerFactory for you by having it injected or looking it up, the container uses a different method on the PersistenceProvider interface implemented by EclipseLink:
EntityManagerFactory createContainerEntityManagerFactory(PersistenceUnitInfo info, Map map)
The long and short of it is that this PersistenceUnitInfo is an interface that the container implements and has these two very key methods on it:
public DataSource getJtaDataSource();
public DataSource getNonJtaDataSource();
With this mode EclipseLink will not try to do its own connection handling and will simply call these methods to get the DataSource from the container. This is really what you need.
There are two possible approaches you could take to solving this:
You could attempt to instantiate the EclipseLink PersistenceProvider implementation yourself and call the createContainerEntityManagerFactory method passing in your own implementation of the PersistenceUnitInfo interface and feed the DBCP configured DataSource instances into EclipseLink that way. You would need to parse the persistence.xml file yourself and feed that data in through the PersistenceUnitInfo. As well EclipseLink might also expect a TransactionManager, in which case you'll be stuck unless you hunt down a TransactionManager you can add to Tomcat.
You could use the Java EE 6 certified version of Tomcat, TomEE. DataSources are configured in the tomee.xml, created using DBCP with full support for all the options you need, and passed to the PersistenceProvider using the described createContainerEntityManagerFactory call. You then get the EntityManagerFactory injected via #PersistenceUnit or look it up.
If you do attempt to use TomEE, make sure your persistence.xml is updated to explicitly set transaction-type="RESOURCE_LOCAL" because the default is JTA. Even though it's non-compliant to use JTA with the Persistence.createEntityManagerFactory approach, there aren't any persistence providers that will complain and let you know you're doing something wrong, they treat it as RESOURCE_LOCAL ignoring the schema. So when you go to port your app to an actual certified server, it blows up.
Another note on TomEE is that in the current release, you'll have to put your EclipseLink libs in the <tomcat>/lib/ directory. This is fixed in trunk, just not released yet.
I'm not sure how useful these slides will be without the explanation that goes along with them, but the second part of this presentation is a deep dive into how container-managed EntityManager's work, specifically with regards to connection handling and transactions. You can ignore the transaction part as you aren't using them and already have an in production you're not likely to dramatically change, but it might be interesting for future development.
Best of luck!
I need to be able to circumvent the whole deployer malarkey and programmatically register/unregister (dependency-less) POJOs as services in JBoss.
Currently I'm dynamically creating an MBean interface and registering this with the JBoss MBeanServer, and then registering local/remote with Jndi.
This works ok (I can have a standard service from a vanilla SAR reference one of these service POJOs with the #EJB annotation) - however the container seems to leaves stale references behind as after calling unbind() and unregisterMBean().
Obviously I'm missing something by not dealing with the container in a way it expects, but what am I missing? Or is there an easier way (can't see much in the way of an API)?
thanks.