Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Q1:
What does “transactional” strategy guarantee?
Q2:
What is the difference between “transactional” strategy and “read/write” strategy with JTA as transaction manager (specified by property).
Q3:
What if I specify “transaction” strategy for some entity in a .hbm.xml file and then will use L2 cache which does not support “transaction” strategy.
For Q1 – Transactional means two things in my understanding. If you have synchronous replication, your transaction will pause until all nodes get the replicated change. if you have asynchronous replication, you can be sure that your other nodes will see the changes in the isolation level chosen (e.g. read committed) and will comply with commits and role backs.
It also means that if an error occurred in the database, or another exception thrown (causing a rollback in case of a transactional aspect on the caller) the cache will also perform a rollback to the changes – keeping a synchronization between cache and database.
note that this requires a JPA transaction manager.
For Q2 – Read/Write is not cluster safe, it doesn’t guarantee data consistency between nodes
For Q3 – Never tried, but it will probably fail with a nice Exception