JTA transaction support for JBoss data grid in remote mode - caching

I am setting jboss data grid in remote client server mode. Entities in cache are hardly updated but retrieved frequently as it is all master data for my application. I am loading the cache with master data from database on application startup. when the entities are updated from application, I want to ensure these are updated in database and grid in one transaction. Is it possible in remote mode?
I have read in documents that JTA transactions are only supported in JBoss Data Grid's Library Mode.
If operation is not possible in single transaction whats is the best way to ensure consistency between data grid cache entities and database?

Related

Spring Boot application with Redis cache without database

I am using Spring Boot application , I have below requirement.
I would like to cache all the rows from a particular table(here I have to convert the row into a particular xml format and maintain that in cache) and then also if any updates happens to that row by another application then in my application I will receive an message from Kafka topic. So I want to update the existing xml in the cache with the latest xml message from Kafka topic.
Here I want to use Redis cache, so far what ever the examples I saw are dealing with database only. So I want to know how I can populate cache from a Kafka topic message(or any xml message).Is it possible to cache an xml message in spring boot using Redis cache? Can some body share idea or any practical example?

How to use Apache Ignite as a layer between Spring Boot app and MongoDB?

I have a Spring Boot application that uses MongoDB. My plan is to store data in a distributed caching system before it gets inserted into Mongo. If the database fails, the caching will have a queue and send to the DB once it is up. So, the plan is to make the caching layer in between the application and Mongo.
Can you suggest some ideas on how to implement this using Apache Ignite?
Take a look at write-behind cache store mode. It retries writing to the underlying database if insertion to the underlying DB fails. Let me know how it works for you.
You can also implement a custom CacheStore for an Ignite cache that will do the caching and enable write through for it. If the connection is lost, then you'll be able to collect entries in a buffer, while retrying to establish the connection back.
See more: https://apacheignite.readme.io/docs/3rd-party-store

How to Restart Spring boot application (or just a particular instance of a class) when flyway migrate is ran or a new schema version is added

I have a particular instance of a class that loads some data from the database, so every time the database is updated the system should recreate the instance of that class to get the updated data
There are trivial several solutions:
(1) Use scheduling to load the latest data from DB periodically.
(2) Provide a web service such as RESTful API to load the latest data from DB.
(3) If your DB supports event-driven listeners, you can trigger your application to achieve this either by invoking a service described in (2) or send a message to queue and handle it by consumer.

weblogic11g datasource not releasing the connections to the pool

We have developed a Java application with the below specifications.
Frameworks: spring,hibernate
Database: oracle
Server: weblogic 11g
Problem here is when we use Weblogic Data Source the connections are not releasing to the pool which is causing Database server RAM consumption completely after some transactions. But when we use basic Data source in the application the connections are releasing immediately after each transaction and there was no RAM consumption at Database server end. How can I use container based data source?
This will depend on the parameters which you have selected while configuring data source for weblogic. Please check the following
1) Do not enable "Pinned to Thread" properties
2) Enable "Inactive connection time out" to appropriate value. It may be possible that you application has leaked connection

Sharing JMS and Hibernate transactions in a Spring MDB using Oracle Streams AQ?

I'm using Oracle 11g for my database and its Oracle Streams AQ feature as JMS implementation.
For all I know, it should be possible to implement a Spring based message-driven POJO (MDP) that uses the same data source for both transactional data access and JMS transactions -- all without XA-Transactions (IIRC, this was marketed as a feature of SpringSource Advanced Pack for Oracle).
Is this possible using Hibernate as well? Ideally, my MDP would start a JMS transaction and read a message from a queue, then re-use the transaction for data access through Hibernate. If anything goes wrong, the JMS and database transaction would both be rolled back, without using 2-phase commit (2PC).
I'm not much of a transaction guru, so before I start digging deeper, can anyone confirm that this is possible and makes sense as well?
Update:
What I want is an implementation of the Shared Transaction Resource pattern. The sample code demonstrates it for ActiveMQ and JDBC, but I need to use Oracle Streams AQ and Hibernate.
Update2:
The SpringSource Advanced Pack for Oracle has been open sourced as part of Spring Data JDBC and it "provides the option of using a single local transaction manager for both
database and message access without resorting to expensive distributed 2-phase commit
transaction management".
2PC shouldn't be necessary, as you say, since the appserver should take care of it. However, you'll pretty much have to use JTA (i.e. JavaEE container) transactions, rather than vanilla DataSource transactions, since JMS only works with JTA.
This isn't a big deal, it's just a bit more fiddly:
Your Spring config should use
<jee:jndi-lookup/> to get a
reference to your container's
DataSource, and you inject that
data source into your spring-managed
hibernate SessionFactory.
You then need to introduce a transaction manager into the context (<tx:jta-transaction-manager/> should work in most app-servers).
In your Spring JMS MessageListenerContainer, plug the above transaction manager reference into it.
Does that all make sense, or should I elaborate? This setup should ensure that the container-managed transactions are held across JMS and Hibernate interactions.

Resources