Develop Reference

update a spring cache when a table update happens through sql procedure

I have a spring boot application with java 8 ,jpa etc and a jboss application with j2ee applications which calls too many sql procedures to update the table.
I have a query something like this in spring boot to get all the employee:
#Cacheable("employeeList")
List{Employee} findByAddressId(Long addressId);
But if someone inserts a new record to Employee table in the same address id from sql procdure from jboss application, the spring boot application is not able to pick the new records , because the query is so generic to that address id.
So i want to create a trigger on that table on insert and update , so when ever insert/update happens it should update the cache with new records belongs to that address id.
Can somebody please tell me how to do this?

If I understand the question correctly you have a spring boot app and a separate jboss app that are connecting to the same database and are insert/updating to the same database tables.
With spring's #Cachable you need to be able to tell spring when you should evict the cached item. For example, having the method that updates the entity being marked as #CacheEvict is an easy way to evict the entity from the cache. The problem here is that if the jboss app updates a record there is no way for spring boot app to know this.
Using a database trigger would seem problematic since you'd have to somehow have the db trigger communicate to the spring boot app to allow eviction to happen.
One solution may be having both the jboss and spring boot app use a distributed caches, like ehcache with terracotta.

Hiberate Envers and threads

I want to know, is it possibile to force Hibernate to call my custom RevisionListener in the same thread as the user session thread? (GWT)
I need such behaviour to store in revisions name of user, who is making the changes.

The hibernate and envers engine run on the thread which boots up the framework and there is no way to delegate the execution of the listeners to other threads.
The information your listener needs should be passed or provided at invocation time and your listener could use a ThreadLocal to lookup the value and use it much like how spring security based applications get this information in the revision listeners via SpringSecurityContextHolder.

Fallback Database with Hibernate

do someone of you know a way to have 2 Databases running parallel?
We are using Hibernate 4 and as a main database Postgres 9.3 - this db is hosted on another machine then the application - if the database is down we still have to save some stuff.
So first intention was to write it into a csv, but I'm not a friend of writing stuff into an unordered file. So I want just to use a fallback Database (thinking of H2 Database). Does someone has experience with such a construct?
We are also using Spring 4 - I would just set up another datasource + sessionfactory + transactionmanager - and add the name at the #Transactional method to use the right manager. any other ideas?
Thank you!!

You can extend the Spring AbstractRoutingDataSource and configure two actual data sources:
a primary PostgreSQL data source
a secondary H2 data source
The application logic will see only one data source, which is the router which will decide which data source is going to switch to on demand.
When the primary data source is down you need to instruct the router to pick the fall-back H2 one.

Using Spring, JPA with Hibernate to access multiple databases/datasources configured in Jboss

I have a requirement where i need to configure a Spring based application to work with two databases. We have two databases, one that we use to keep the live data and the other database is used as a datawarehouse and contains archived data (which has the exact structure as the Live db).
To keep it simple, assume that there is a request to search for a product. What the application should do is to search for the product details in the Live database and if not found it will check the archive database.
If i need to configure such a setup, do i still need to configure to datasources and would the search code have to use the first datasource to check the live database and if not found it will run another query using the archive database?
The above is probably doable but i am wondering whether there is a better way of doing this. For example, is it possible for the application to work on a single datasource even though behind the scenes it actually works with two databases?
The application is based on Spring, JPA/Hibernate, SOAP and Mysql database and Jboss 7 as the application server.
Any examples showing how this is configured using Spring and Jboss would be very useful.
Thanks

Spring has exactly what you want - the AbstractRoutingDataSource. See this blog post on how to use it. In your case, you need to switch the datasource during one request, so you'll need to have 2 transactions, switching the datasource between them by changing the datasource indicator on the ThreadLocal:
For these DAOs, demarcate the wrapping Service-layer either with distinct packages, class names, or method names
Indicate to Spring that the Service-layer method calls should run in their own transactional contexts by annotating with #Transactional(propogation=Propogation.REQUIRES_NEW)
Create an Aspect (using AspectJ annotation #Aspect) to fire around the service-layer method calls (using #Around) to set the ThreadLocal value before the method call, and to unset it afterwards
In the #Controller, simply call the Service-layer methods. The Aspect will take care of setting the values to indicate which datasource to use, and the AbstractRoutingDataSource will use that datasource in the context of each transaction.

Managing database transactions manually in a Spring/Hibernate environment

We've got a Spring based web application that makes use of Hibernate to load/store its entities to the underlying database.
Since it's a backend application we not only want to allow our UI but also 3rd party tools to manually initiate DB transactions. That's why the callers need to
Call a StartTransaction method and in return get an ID that they can refer to
Do all DB relevant calls (e. g. creating, modifying, deleting) by referring to this ID to make clear which operations belong to the started transaction
Call the CommitTransaction method to signal to our backend that the transaction can be committed now (or in the negative case RollbackTransaction will be called)
So keeping in mind, that all database handling will be done internally by the Java persistence annotations, how can we open the transaction management to our UI that behaves like a 3rd party application that has no direct access to the backend entities but deals with data transfer objects only?

From the Spring Reference: Programmatic transaction management

I think this can be done but would be a royal pain to implement/verify. You would basically require a transaction manager which is not bounded by "per-thread-transaction" definition but spans across multiple invocations for the same client.
JTA + Stateful session beans might be something you would want to have a look at.

Why don't you build services around your 'back end application' for example a SOAP interface or a REST interface.
With this strategy you can manage your transaction in the backend