I am trying to upgrade my spring transaction manager from JtaTransactionManager to HibernateTransactionManager. In JTA TransactionManager we have one method which gives the status of current transaction. Based on the status we are doing some operations. The implementation is as follows :
private void checkTransactionStatus(TransactionStatus status){
if(status instanceof DefaultTransactionStatus) {
DefaultTransactionStatus transactionStatus = (DefaultTransactionStatus) status;
if(transactionStatus.getTransaction() instanceof JtaTransactionObject){
JtaTransactionObject txObject = (JtaTransactionObject) transactionStatus.getTransaction();
int jtaStatus;
try {
jtaStatus = txObject.getUserTransaction().getStatus();
if(jtaStatus==Status.STATUS_MARKED_ROLLBACK){
// logic heare
}
} catch (SystemException e) {}
}
}
}
I want to replace this method with HibernateTransactionManager specific code. I analyzed and found that, HibernateTransactionManager is using HibernateTransactionObject as transaction object. But, unfortunately it's a private inner class that I can't use to get the status. Then I tried to use the parent class JdbcTransactionObjectSupport. But, I don't know how to get the status from this parent class object.
private void checkTransactionStatus(TransactionStatus status){
if(status instanceof DefaultTransactionStatus) {
DefaultTransactionStatus transactionStatus = (DefaultTransactionStatus) status;
if(transactionStatus.getTransaction() instanceof JdbcTransactionObjectSupport){
JdbcTransactionObjectSupport txObject = (JdbcTransactionObjectSupport) transactionStatus.getTransaction();
//how to get the current status ?
}
}
}
Spring has a mechanism for receiving callbacks. You can implement the TransactionSynchronization interface (or easier extend the TransactionSynchronizationAdapter). You probably want to implement the afterCompletion(int) method and put your logic in there.
public class MyTxCallback extends TransactionSynchronizationAdapter {
public void afterCompletion(int status) {
if (status==STATUS_ROLLED_BACK) {
//logic here.
}
}
}
You can then bind that to the transaction by calling the TransactionSynchronizationManager when a transaction is started. Now when the transaction is done the method will be called and you can do your logic (regardless of the underlying transactional resource used).
If you use HibernateTransactionManager you can get the current transaction state from the Hibernate Session:
LocalStatus status = session.getTransaction().getLocalStatus();
and the LocalStatus has the following states:
public enum LocalStatus {
/**
* The local transaction has not yet been begun
*/
NOT_ACTIVE,
/**
* The local transaction has been begun, but not yet completed.
*/
ACTIVE,
/**
* The local transaction has been competed successfully.
*/
COMMITTED,
/**
* The local transaction has been rolled back.
*/
ROLLED_BACK,
/**
* The local transaction attempted to commit, but failed.
*/
FAILED_COMMIT
}
Related
I developed a typical enterprise application that is responsible for provisioning customer to a 3rd party system. This system has a limitation, that only one thread can work on a certain customer. So we added a simple locking mechanism that consists of #Singleton which contains a Set of customerIds currently in progress. Whenever a new request comes for provisioning, it first checks this Set. If cusotomerId is present, it waits otherwise it adds it to the Set and goes into processing.
Recently it was decided, that this application will be deployed in cluster which means that this locking approach is no longer valid. We came up with a solution to use DB for locking. We created a table with single column that will contain customerIds (it also has a unique constraint). When a new provisioning request comes we start a transaction and try and lock the row with customerId with SELECT FOR UPDATE (if customerId does not exist yet, we insert it). After that we start provisioning customer and when finished, we commit transaction.
Concept works but I have problems with transactions. Currently we have a class CustomerLock with add() and remove() methods that take care of adding and removing customerIds from Set. I wanted to convert this class to a stateless EJB that has bean-managed transactions. add() method would start a transaction and lock the row while remove() method would commit transaction and thus unlocked the row. But it seems that start and end of transaction has to happen in the same method. Is there a way to use the approach I described or do I have to modify the logic so the transaction starts and ends in the same method?
CustomerLock class:
#Stateless
#TransactionManagement(TransactionManagementType.BEAN)
public class CustomerLock {
#Resource
private UserTransaction tx;
public void add(String customerId) throws Exception {
try {
tx.begin();
dsApi.lock()
} catch (Exception e) {
throw e;
}
}
public void remove(String customerId) throws Exception {
try {
tx.commit();
} catch (Exception e) {
throw e
}
}
}
CustomerProvisioner class excerpt:
public abstract class CustomerProvisioner {
...
public void execute(String customerId) {
try {
customerLock.add(customerId);
processing....
customerLock.remove(customerId);
} catch (Exception e) {
logger.error("Error", e);
}
}
...
}
StandardCustomerProvisioner class:
#Stateless
public class StandardCustomerProvisioner extends CustomerProvisioner {
...
public void provision(String customerId) {
// do some business logic
super.execute(customerId);
}
}
As #Gimby noted, you should not mix container-managed and bean-managed transactions. Since your StandardCustomerProvisioner has no annotation like "#TransactionManagement(TransactionManagementType.BEAN)" - it uses container-managed transactions, and REQUIRED by default.
You have 2 options to make it work:
1) To remove "#TransactionManagement(TransactionManagementType.BEAN)" with UserTransaction calls and run CMT
2) Add this annotation ("#TransactionManagement(TransactionManagementType.BEAN)") to StandardCustomerProvisioner and use transaction markup calls from this method, so all the invoked methods use the same transactional context. Markup calls from CustomerLock should be removed anyway.
Is there any way to get current transaction id, store/pass it, and check it's status in the another part of application?
For example:
#Service
public class Service {
...
#Transactional(rollbackFor = Exception.class)
public void performAction(Action action) {
// start action
String transactionId = ??? // getting current transaction id
messenger.send(transactionId); // sending transaction id to consumer
// continue action
} <- commit transaction
}
public class Consumer {
...
public void onRecieveMessage(String transactionId) {
TransactionStatus ts = ??? // getting transaction from pool by id
if (ts.isCompleted()) {
// some actions
} else {
// wating or Future<?> or something else...
}
}
}
(Actually, the problem is Consumer.onRecieveMessage executes earlier than action's transaction finishes, and data state is old)
I do not know any way of getting a specific transaction by its ID (hopefully someone does).
What I would do is to implement an instance of TransactionSynchronization that holds a kind of value you want to track:
public class YourTransactionTracker extends TransactionSynchronizationAdapter {
private Value value;
public YourTransactionTracker(Value value) {
this.value = value;
}
#Override
public void afterCompletion(int status) {
//transaction handling your 'value' has been completed with the status 'status'
//do whatever you want here
}
//you can also override other methods like beforeCompletion(), flush(), etc...
//have a look at TransactionSynchronizationAdapter
}
TransactionSynchronizationAdapter is just an implementation of TransactionSynchronization with empty methods.
Then you can hook a callback in the transaction with your TransactionSynchronization instance, that will be called in the different stages of the lifecycle of the transaction.
You can do this in Spring by using the TransactionSynchronizationManager:
TransactionSynchronizationManager.registerSynchronization(
new YourTransactionTracker(theValueYouAreTracking);
I am attempting to write to multiple databases using hibernate. I have encapsulated write and read/write sessions within a single session object. However, when I go to save I get a lot of errors that the objects are already associated with another session: "Illegal attempt to associate a collection with two open sessions"
Here is my code:
public class MultiSessionObject implements Session {
private Session writeOnlySession;
private Session readWriteSession;
#Override
public void saveOrUpdate(Object arg0) throws HibernateException {
readWriteSession.saveOrUpdate(arg0);
writeOnlySession.saveOrUpdate(arg0);
}
}
I have tried evicting the object and flushing; however, that causes problems with "Row was updated or deleted by another transaction"... even though both sessions point to different databases.
public class MultiSessionObject implements Session {
private Session writeOnlySession;
private Session readWriteSession;
#Override
public void saveOrUpdate(Object arg0) throws HibernateException {
readWriteSession.saveOrUpdate(arg0);
readWriteSession.flush();
readWriteSession.evict(arg0);
writeOnlySession.saveOrUpdate(arg0);
writeOnlySession.flush();
writeOnlySession.evict(arg0);
}
}
In addition to the above, I have also attempted using the replicate functionality of hibernate. This was also unsuccessful without errors.
Has anyone successfully saved an object to two databases that have the same schema?
The saveOrUpdate tries to reattach a given Entity to the current running Session, so Proxies (LAZY associations) are bound to the Hibernate Session. Try using merge instead of saveOrUpdate, because merge simply copies a detached entity state to a newly retrieved managed entity. This way, the supplied arguments never gets attached to a Session.
Another problem is Transaction Management. If you use Thread-bound Transaction, then you need two explicit transactions if you want to update two DataSources from the same Thread.
Try to set the transaction boundaries explicitly too:
public class MultiSessionObject implements Session {
private Session writeOnlySession;
private Session readWriteSession;
#Override
public void saveOrUpdate(Object arg0) throws HibernateException {
Transaction readWriteSessionTx = null;
try {
readWriteSessionTx = readWriteSession.beginTransaction();
readWriteSession.merge(arg0);
readWriteSessionTx.commit();
} catch (RuntimeException e) {
if ( readWriteSessionTx != null && readWriteSessionTx.isActive() )
readWriteSessionTx.rollback();
throw e;
}
Transaction writeOnlySessionTx = null;
try {
writeOnlySessionTx = writeOnlySession.beginTransaction();
writeOnlySession.merge(arg0);
writeOnlySessionTx.commit();
} catch (RuntimeException e) {
if ( writeOnlySessionTx != null && writeOnlySessionTx.isActive() )
writeOnlySessionTx.rollback();
throw e;
}
}
}
As mentioned in other answers, if you are using Session then you probably need to separate the 2 updates and in two different transactions. The detached instance of entity (after evict) should be able to be reused in the second update operation.
Another approach is to use StatelessSession like this (I tried a simple program so had to handle the transactions. I assume you have to handle the transactions differently)
public static void main(final String[] args) throws Exception {
final StatelessSession session1 = HibernateUtil.getReadOnlySessionFactory().openStatelessSession();
final StatelessSession session2 = HibernateUtil.getReadWriteSessionFactory().openStatelessSession();
try {
Transaction transaction1 = session1.beginTransaction();
Transaction transaction2 = session2.beginTransaction();
ErrorLogEntity entity = (ErrorLogEntity) session1.get(ErrorLogEntity.class, 1);
entity.setArea("test");
session1.update(entity);
session2.update(entity);
transaction1.commit();
transaction2.commit();
System.out.println("Entry details: " + entity);
} finally {
session1.close();
session2.close();
HibernateUtil.getReadOnlySessionFactory().close();
HibernateUtil.getReadWriteSessionFactory().close();
}
}
The issue with StatelessSession is that it does not use any cache and does not support cascading of associated objects. You need to handle that manually.
Yeah,
The problem is exactly what it's telling you. The way to successfully achieve this is to treat it like 2 different things with 2 different commits.
Create a composite Dao. In it you have a
Collection<Dao>
Each of those Dao in the collection is just an instance of your existing code configured for 2 different data sources. Then, in your composite dao, when you call save, you actually independently save to both.
Out-of-band you said you it's best effort. So, that's easy enough. Use spring-retry to create a point cut around your individual dao save methods so that they try a few times. Eventually give up.
public interface Dao<T> {
void save(T type);
}
Create new instances of this using a applicationContext.xml where each instance points to a different database. While you're in there use spring-retry to play a retry point-cut around your save method. Go to the bottom for the application context example.
public class RealDao<T> implements Dao<T> {
#Autowired
private Session session;
#Override
public void save(T type) {
// save to DB here
}
}
The composite
public class CompositeDao<T> implements Dao<T> {
// these instances are actually of type RealDao<T>
private Set<Dao<T>> delegates;
public CompositeDao(Dao ... daos) {
this.delegates = new LinkedHashSet<>(Arrays.asList(daos));
}
#Override
public void save(T stuff) {
for (Dao<T> delegate : delegates) {
try {
delegate.save(stuff);
} catch (Exception e) {
// skip it. Best effort
}
}
}
}
Each 'stuff' is saved in it's own seperate session or not. As the session is on the 'RealDao' instances, then you know that, by the time the first completes it's totally saved or failed. Hibernate might want you to have a different ID for then so that hash/equals are different but I don't think so.
Hi I have tested this code with junit 4:
public class UserDaoTest {
/**
* Runs before all test methods
*/
#BeforeClass
public static void createDB() {
sessionFactory = HibernateUtil.getSessionFactory();
userDao = new UserDaoImpl();
languageDao = new LanguageDaoImpl();
requestDao = new RequestDaoImpl();
feedbackDao = new FeedbackDaoImpl();
hostelDao = new HostelDaoImpl();
imageDao = new ImageDaoImpl();
}
/**
* Runs after all test methods
*/
#AfterClass
public static void closeSessionFactory() {
HibernateUtil.shutdown();
}
/**
* Runs before each test method
*
* #return
*/
#Before
public void beginTransaction() {
session = sessionFactory.getCurrentSession();
transaction = session.beginTransaction();
}
/**
* Runs after each test method
*/
#After
public void rollbackTransaction() {
if (transaction != null && transaction.isActive()) {
System.out.println("Rolling back trasnaction after #Test method");
// rollback transaction so that tests don't modify database
transaction.rollback();
}
}
#Test
public void testSaveUser() {
User user1 = new User("Ostap", "Stashyshyn", Gender.MALE);
// save user. It delegates to `session.save(user1)` method.
userDao.create(user1);
Integer userId = user1.getUserId();
Assert.assertNotNull(userId);
// causes persistent entities to be saved into persistent context
session.flush();
// read languages from db
List<User> users = userDao.readAll();
Assert.assertThat(users.size(), CoreMatchers.is(1));
// next method annotated with #After is running.
// It rollbacks transaction causing hibernate not to store data into database. Thus database state is the same as when entering this test method
}
It tests successfully, but when I set breakpoint after session.flush() and go to db from command line I see that there is no row for user.
Calling userDao.readAll(); causes hibernate to issue select statement and return users?
I see insert and select statements on console but nothing in db. But when I call transaction.commit() instead of session.flush() then appropriate data is in db.
Is above code correct way to test saving user? Or I should call transaction.commit() instead of session.flush()?
EDIT: I shall adhere to this way of testing org.hibernate.Session?
Thank you!
The session used in this test is a different session to the db session you got from command. Until transaction.commit(), you will not see any data changes by your test.
Your test is valid! You should not use transaction.commit() instead of session.flush() as it will persist your test data and make your next run harder.
You only do transaction.commit() instead of session.flush() if you want to debug your test and verify the test data manually/
session.flush() doesn't mean that persistent object will be written to database. flush will only responsible for synchronizing the underlying persistent store with persistant state held in memory. in simple word it will update or insert into your tables in the running transaction, but it may not commit those changes all this is depends on FlushMode setting.
As the code given by you is not complete so its difficult to tell wther its correct or not. Because what you have written in userDao.create() is hiiden? Where you beginning Transaction is also not clear.
I have a method that save a object but I need consumes an API and save their return. If the API return is "not authorized", I need rollback the transaction but I want preserve the return.
E.g.
#Resource
private SessionContext context;
#Transactional
public Invoice createSale(SaleDTO saleDTO) {
this.dao.save(saleDTO);
Send send = this.context.getBusinessObject(Send.class);
Invoice invoice = this.send.send(saleDTO);
if (invoice.isAuthorized()) {
invoice.setSale(saleDTO);
return invoice;
} else {
throw new IllegalArgumentException();
}
}
public class Send implements Serializable {
#Transactional(Transactional.TxType.REQUIRES_NEW)
private Invoice send(SaleDTO saleDTO) {
Invoice invoice;
...
this.dao.save(invoice);
return invoice;
}
}
When I thrown the IllegalArgumentException, the invoice is not saved. I need save it.
Annotating a private method, or even a public method called from another method of the same class, can't work.
Transactional handling is based on proxies.
A transaction can only be started if you call a transactional method on another bean, injected in the current bean, so that the transactional proxy wrapping the other bean intercepts the call and starts a transaction.
Read https://docs.spring.io/spring/docs/current/spring-framework-reference/data-access.html#tx-decl-explained. You don't seem to use Spring, but the way it works in Java EE is the same.