Hibernate Ehcache Operations and Event Handlers - database

I currently have my application integrated with Hibernate. It saves/retrieves data from the database successfully. Next, I would like to configure ehcache such that my application does not have to hit the database every time.
That being said, I was wondering if there are any ehcache event handlers that would allow me to run some custom piece of code before (or after) a cache operation (i.e. put, remove, get, etc.)?
Also, when my application is about to save a DAO, my understanding is hibernate will push that to the database. What I would like to know whether the db operation will be performed before, during or after the event handler (above) is triggered?

Perhaps you could create a CacheEventListener which would allow you to receive notifications of put/update/remove events - and then you could perform some action accordingly. The notification occurs after the event has happened.
You configure a listener in the ehcache.xml file on a per-cache basis:
<cache ...>
<cacheEventListenerFactory class="your.listener.FactoryClass" />
...
</cache>
Where the cacheEventListenerFactory is a class that you create which in turn creates your listener. See the EHCache docs for more detailed info.
For integration of EHCache with Hibernate, you should look at the EhCacheRegionFactory. Again see the docs for step by step instructions of how this is set up.

Related

How to test Spring database down?

I have this SpringBoot server app using PostgreSQL database if it's up and sending error response if it's down. So my app is running regardless the database connection.
I would very much like to test it (jUnit / mockmvc).
My question is very simple, yet I did not find the answer online:
how does one simulate a database connection loss in SpringBoot?
If anyone wants, I can supply code (project is up at https://github.com/k-wasilewski/workshop/)
Have you thought of Testcontainers? You can spin up your docker image through a Junit test and make your spring boot use that as your database.
Since you use junit, you can start/stop this container at will.
This will generate a test which creates the condition you are looking for and write code as to what to expect when the database is down.
Here are some links to get started,
Testcontainers and Junit4 with Testcontainers quickstart - https://www.testcontainers.org/quickstart/junit_4_quickstart/
Spring boot documentation - Use Testcontainers for integration testing
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#howto-testcontainers
Testcontainer github link example for springboot app
https://github.com/testcontainers/testcontainers-java/tree/master/examples/spring-boot
Testcontainer - Generic container javadoc. You can find methods for start/stop
container here. call from your Junit.
https://javadoc.io/static/org.testcontainers/testcontainers/1.12.4/org/testcontainers/containers/GenericContainer.html
You can implement your own Datasource based on DelegatingDataSource and then let it throw exceptions instead of delegating when ever you want to.
I've done this before by creating a Spring Boot test configuration class that created the DataSource and wrapped it in a Java proxy. The proxy simply passed method calls down to the underlying DataSource, until a certain flag was set. Once the flag was set, then any method called on the proxy would throw an exception without calling the underlying DataSource. Essentially, this allowed me to "bring the database down" or "up" simply by flipping the flag.

Azure Event Hub log sorting streaming using query

How to process Azure Log events from Event hub and filter based on criteria.
We are trying to filter specific critical or security related Diagnostic and Activity logs before feeding into our Onprem SIEM solution.
Can someone please guide me how to filter the data from Event hub and then re-ingest into another event hub. Whether this is possible or any other alternatives available out there.
At a high level , the flow is shown below. Source from Diagnostic Logs (Monitor) -> Event Hub -> Filter/Query -> Event Hubenter image description here
The answer could be very bare - but in our case we are using Azure Functions to perform similar operations.
As you know the shape of data - the function can decide if event is forwarded to other EH or it is dropped.

SqlDependency not working

I'm using EF 6 with SQL Server 2012.
I'm trying to use SqlDependency to refresh my cached data, in a class library (DLL).
I have the following, based on whatever guides I found, but seems like it is not working, and I get no error.
enabled broker service on the db
created the broker queue, and the service
Using sa login.
I'm testing this whole thing through unit testing code, not sure maybe the notification is not instantaneous, my breakpoint in SqlDependency.OnChange never triggered.
But even if I purposely slow down the post-changes, OnChange is still not triggered.
Once I made relevant data changes, how can I know SQL Server is generating a notification in db?
Update:
Initially I found "master key encryption is required" in SQL log. By creating that key, the log no longer happened, but OnChange is still not triggered.
After many trials, and based on 1 important article:
http://www.codeproject.com/Articles/12335/Using-SqlDependency-for-data-change-events
1) After SqlDependency is initialized, must execute the SqlCommand, can simple just invoke sqlCmd.ExecuteNonQuery().
2) After OnChange event triggered, must remove the event handling, recreate a new SqlCommand and SqlDependency, rebind the event handling, and follow rule #1

Should I need a database to ensure immediate consistency with a message-oriented middleware?

App A wants to send domain events to App B through a middleware like RabbitMQ.
Let's take the example of one domain event called UserHasBeenRegistered, involving by the creation of the User entity.
A would inform B that this latter should send a welcome email, by sending this event.
I have in mind two workflows:
First:
- App A registers the user and the event is generated.
- App A sends the event directly to B through a queue provided by RabbitMQ
Second:
- App A registers the user and the event is generated.
- App A saves the event in some kind of event store as a database table (if relational) in the same local transaction used for persisting in database this new user.
- An asynchronous scheduler queries the event store, find this new user registration and sends the message through the RabbitMQ's queue.
Do you see the difference?
Yes, one is longer than the other... but the second is far more safe! albeit less performant.
Indeed, what while in the first case, the registration is rollback due to an exception thrown just after the publishing was made? => the mail would be sent whereas the user was not persisted.
This could be fixed by implementing a global XA transaction (two-phases commit), but it is well known that some middleware don't support it.
Therefore, is the second workflow mostly used in critical application?
What are its drawbacks?
I plan to implement one of both solutions for my project.
I had the same task and it was done as a mix of your two workflows:
App A registers the user and the event is generated.
App A sends the event which has ttl set to non-zero value directly to B through a queue provided by RabbitMQ.
App B receive event and send welcome message to user and store flag that welcome message sent.
There are background script which check whether there are newly registered users from last ttl + 1 time interval who doesn't receive messages.
You can remove background script and flag storing and stick with first workflow from you q. The cases when messages lost or any other cases are damn rare (with welcome messages sending it might be 1 failure per 1billion users) and unnecessary application complication may give you more errors.
The second workflow looks also stable, but why you are using RabbitMQ then?

Stateful Bean using #PreDestroy to close database connection

I have a Stateful bean that is used to make a couple database queries. I open the connection in the first method I call, but I only really want to close the connection after the EJB Client is really done with the Stateful bean. I thought that I could put the logic that closes the database connection in the #PreDestroy method.
This seems to be working, but I'm curious as to the implications. When, specifically, does the EJB session complete? This is container managed transactions, so I would assume that when the EJB client method completes, so does the EJB transaction. When, specifically, does the PreDestroy method get called? Is the transaction still around? Or did it already commit and put itself back into the pool? Thanks!
Below are the excerpt from specification, which might clarify the statefull session bean lifecycle.
At the end of the lifecycle, the client invokes a method annotated
#Remove, and the EJB container calls the method annotated #PreDestroy,
if any. The bean’s instance is then ready for garbage collection.
it would be wrong to perform database operations within a session
bean’s PostConstruct or PreDestroy lifecycle callback interceptor
methods and to assume that the operations are part of the client’s
transaction. The PostConstruct and PreDestroy methods are not
controlled by a transaction attribute because handling rollbacks in
these methods would greatly complicate the session instance’s state
diagram.
PreDestroy methods are invoked in an unspecified transaction and security context.
The PrePassivate callback notification signals the intent of the container to passivate the instance. The PostActivate notification signals the instance it has just been reactivated. Because containers automatically maintain the conversational state of a stateful session bean instance when it is passivated, these notifications are not needed for most session beans. Their purpose is to allow stateful session beans to maintain those open resources that need to be closed prior to an instance’s passivation and then reopened during an instance’s activation.

Resources