CODEWITHSUNDEEP
javaspringmultithreadinghibernateserver
mayan anger
mayan anger

Reputation: 2702

Make Spring Hibernate thread safe. Best solation

i searched for multiple ways and soluations to make spring hibrenate to a safe thread. i am little beginner with spring and hibrenate and i just cannot make this decisions alon.

i found these options :

  1. Use hibrenate locking to "sabotage" any transaction that make clash with other transactions, and save the database from wrong data. this have drawback becouse will be transactions that just not executed and it will more complex work to complete thouses requests

  2. Simply run all transaction (at lest all updates) in one thread, this thread will be the "ExecuterThred" and he make share all these transactions will executed in serially order. In this way there is no chance for transactoin clash but this solution make your databse spring server depending on one thread, It can implemented by useig regular java thread, maybe big one like this, or use thread local

  3. Make dao synchronized (or at lest all update method), Is no chance for transactoin clash as well, but can traking the server.

More one something, In my Server, any client have user, and any user have unique id. I thought About More One option : To make share that any client will able to send ONLY ONE request (that make diffrent on the database) on same time. (i can now that, because i can use the unique id), if the client do this anywey i will response with concurrent error and he able to try again letter. this will be option 4.

if you have more option plaese let me know.

Thanks alot, any help or explanation will be most welcome

Upvotes: 1

Views: 312

Answers (1)

Naros
Naros

Reputation: 21113

What gain would that net for most applications that use Hibernate and Spring?

I'd surmise that design would actually be a net loss for most applications because the scenario you describe is really more of a corner case for which existing locking strategies and integrations with other technology stacks can easily mitigate those problems.

You should always first try to work with Optimistic Locking.

In the past, I've used a solution where I maintained a cached copy of the entity that I use as a snapshot of what the database had when a user begins an operation. When the user posts changes back to the server, I modify a second instance of that entity which I then try to save. Whenever Hibernate fails with an optimistic locking exception, I can compare the returned database snapshot with the original cached copy and decide if I can retry the operation or not, asserting if I cannot retry or after X number of retry attempts.

Is that extra code, absolutely. But it is extra code that is use case and business case specific. Some situations, I'd like to fail fast. In others I might want to retry while in others I might just allow whoever changed it last to win.

If updates must be serialized, you could look into using a broker solution like a JMS queue or alike where you post your update operations to and execute in a single handler. This allows you to scale your application as needed and avoids having to embed a background thread in your application. But this does mean your application will have to deal with eventual consistency because if that queue has backlog, it might take seconds or minutes for that update reflect in your application. Also understand the implications if you're using the Second Level Cache (2LC) too.

I honestly think you're trying to over-engineer something where there are already tried-and-proven solutions to deal with precisely the concerns you have. Is there effort in doing it right, absolutely. But no complex solution is ever just a few lines of code either :P.

Upvotes: 1

Related Questions