I'm not completely understand how aries transaction manager works in FUSE ESB 7.1.0. I would be glad if someone can explain the following situation.
I use an jdbc XADataSource (org.postgresql.xa.PGXADataSource) in my bundle and here is what I see: it seems like the aries transaction manager doesn't close a jdbc connection when a message was processed in a transactional route and changes where commited to a DB. Connections leave in the idle state. But after some time they are finally closed.
This led me to big problems when I try to use connection pool: an application exhauses connection pool very fast and all opened connection leave in the busy state.
I have the next questions about the aries transaction manager:
When it does close jdbc connections?
How can I tell it to close a jdbc connection when a message is
processed and changes were committed?
Related
TLDR:
1.Where does atomikos keep its trasnaction records so it can function and how is it best to "secure" them against losing/corrupting them. I use Docker/Docker-Compose and Spring Boot.
2.If the app dies unexpectdly, do all the transactions roll back because atomikos automagically started the appropiate SQL/JMS transactions with the sources?
Details
Hello.
I am starting to use atomikos in Spring Boot to enable XA transactions (in my case simply one datasource and an ActiveMQ/JMS broker.
I have been Googling and can't find a more "in depth" blog or site that explains in a bit more details how Atomikos works under the hood.
I do see the atomikos transaction logs in the form:
{"id":"127.0.1.1.tm159765570032300035","wasCommitted":true,"participants":[{"uri":"127.0.1.1.tm35","state":"COMMITTING","expires":1597655710327,"resourceName":"dataSource"},{"uri":"127.0.1.1.tm36","state":"COMMITTING","expires":1597655710327,"resourceName":"jmsConnectionFactory"}]}
I can only assume these are simply actual "logs" and not like the kafka.db file in say ActiveMQ when using file persistence.
Questions
So does atomikos keep its state in memory?
If say an unexpected shutdown occurred half way through an XA transaction, will all the JTA sources simply rollback?
If the atomikos state is held in a file/database somewhere...are there some best practices when using docker-compose for example?
Example:
A #Component picks out a database entity "REQUIRES_PROCESSING" for queuing on to a JMS queue and then switches the entity to "PROCESSING".
The JMS message is queued but then the App unexpectedly dies before the database entity is set to "PROCESSING".
Will in this case, atomikos has now no state (it died with the app) but it created a SQL and ActiveMQ trasnaction that will simply timeout and everything rolls back?
The application reboots 5 seconds later...what happens here? Is this transaction picked up again somehow (i.e. atomikos has still got state somewhere?).
Will the rebooted app just grab the rolledback entity and simply retry as expected?
Are there any pitfalls here?
Thank you for any claification.
In one of spring boot microservice app, i was having problem with connection leakage. Some of the connection were not being returned to the Pool and i was using only default configuration for Hikari. Now I put a leakDetectionThreshold and it starts explicitly taking back connections and returning it to the Pool. My question is related to these broken connections, even though as per the specification of Hikari pool, if a connection retuned to pool in a broken state, Pool handlers would rollback the transactions so thay It didn't bleed out for the next consumer. But in my case, transactions were not rolled back. What is happening here?
We are using Websphere Applicaion Server with Spring JMS, Around 25 applications connect to a IBM MQ. Off-late we are seeing lots of stale connection on the MQ channel to which all these applications connect.
By stale connections I mean the connection are not being used for many days and the application keeps creating new connections. We are not able to identify which application creates these connections that are not being used but they all use the same framework code
WAS version = 8.5.5
Spring = 4.1.2
The Spring jms:listener-container has the following configuration
connection-factory = org.springframework.jms.connection.DelegatingConnectionFactory
acknowledge=auto
concurrency=2-10
Any pointers on any configurations that can be done on QueueConnectionFactory (JMS Resource) on WAS or on the spring side would be helpful.
I know I have not given much information, but the problem is that there are no errors / exceptions, the application creates these connections to the MQ channel and all connections gets cleared when the server is restarted
Adding one more question
We use org.springframework.jms.connection.DelegatingConnectionFactory , for replying back, Does it make sense for us to close the session once we have send back the message?
Thanks in Advance
Charlie
I have an ActiveMQ broker running as a Windows service. Its using jdbcPersistenceAdapter with Oracle data source and Oracle's Universal Connection Pooling (UCP).
When the database is down (due to network problems or scheduled maintenance), the ActiveMQ windows service shuts down completely. This, of course makes the broker unavailable even after the database is restored.
I have tried connection validation in UCP, DBCP with connection validation and even MySQL data source without any success. The service shuts down within 30 seconds of database failure (I believe this is because the default cleanupInterval is 30 seconds).
Is there a way to prevent the windows service from shutting down and make it wait for database availability?
Any help is greatly appreciated.
Here is my current configuration from activemq.xml:
<persistenceAdapter>
<jdbcPersistenceAdapter dataSource="#oracle-ds"/>
</persistenceAdapter>
<bean id="oracle-ds" class="oracle.ucp.jdbc.PoolDataSourceFactory"
factory-method="getPoolDataSource" p:URL="jdbc:oracle:thin:#localhost:1521:amq"
p:connectionFactoryClassName="oracle.jdbc.pool.OracleDataSource"
p:validateConnectionOnBorrow="true" p:user="appuser" p:password="userspassword" />
generally, you should use a JDBC master/slave to support failover from another broker when the database becomes unavailable...
see http://activemq.apache.org/jdbc-master-slave.html
that said, there is a known issue with JDBC master/slave failover that was fixed in 5.6.0...
see https://issues.apache.org/jira/browse/AMQ-1958
I think I am not getting something right with JMS and JTA. I am running in a Java EE container with all CMTs. Here is what I am doing:
In an SLSB, write something to the database
From the same method of the SLSB, post a message to a JMS queue
An MDB in the same container listens to the JMS queue and picks up the message
The MDB reads the database
The problem is, the MDB does not see the changes made to the database in step 1.
I verified that steps 1 and 2 happen inside a single XA transaction, as expected. My expectation is that a second XA transaction would start at step 3, after the first XA has been committed. But it seems that the MDB receives the message before the XA transaction that posted the message has been committed.
Is my expectation wrong and what I am seeing is normal?
I am running under JBoss 6. The SLSB is local. Both the SLSB and the MDB are in the same application.
I found the problem! My JMS connection factory was not XA aware. I had looked up /XAConnectionFactory for my JMS connection factory. In spite of the name, that's the wrong resource to lookup for a regular app in JBoss. There is a java:/XAConnectionFactory too, which does not work either. The correct resource name is java:/JmsXA. I used it and everything is working just as expected.
Thanks to #strmqm for nudging me to the right direction.
I saw a conceptually similar problem in an app built w/ WebLogic 7. The DB commit from tx1 wasn't complete by the time that tx2 (initiated by a JMS send in tx1) tried to read it.
The trouble there was that our configuration involved a WLS 7 XA emulation layer with a non-XA db connection (to Oracle DB). This risk was part of that XA shortcut. Apparently if we'd gone w/ the true XA all the way to the DB, that hole would have closed. Never ended up testing that.
You say this is JBoss. Any chance that they've got some similar shim that bypasses the XA and gives this same surprising result?