I have the following code fragments:

$Stateless
public testEJB
{
@PersistenceContext(unitName = "testunit")
private EntityManager entityManager;

public void modifyTest() { //update a record
deleteTest();
addTest();
}

public deleteTest() //delete a record from db
{
entityManager.remove(..);
}

public addTest() //insert a record to db
{
entityManager.persist(..);
}
}

The deleteTest() and addTest() methods both work fine. However, the modifyTest() does not work! It keeps complaining about unique key constraints. Seems to me that the deleteTest() call does not really remove the original record and therefore the addTest() can not execute properly because it thinks another record with an exisiting key is being inserted. Or maybe the entityManager is still seeing the stale data? Anyway, if I add the entityManager.flush() then it works.

public void modifyTest() { //update a record from db
deleteTest();
entityManager.flush();
addTest();
}

Can someone please explain to me why this is happening? Shouldn't the flush happen automatically? when deleteTest() is called? By the way, I am using the hibernate entitymanager.

Thanks a lot for your help!

Joanne

It's an edge case, adding before deleting is necessary to avoid FK constraints. Manually call flushing is the correct fix.

Thanks for clarifying this me.

My next question is, how can I make this piece of code more transaction friendly?
let's assume that during one method call to modifyTest(), the deleteTest() completes successfully, but the addTest() throws an exception. In this case, because I manually flushed the entityManager after deleteTest(), this record is removed from database although the new insertion does not work. How can I make sure these two are inside one atomic transaction? So if there is a problem with the new data, the old data should not be removed.

I understand that entityManager.merge is probably a better approach to update a database record, but I have to use this delete/add combination for some other business reasons.

Thanks a lot for your help!

Joanne

Flushing has nothing to do with transaction
You modify method will be marked as transactional (annotations if you use EJB3), and the 2 suboperations will be part of a single tx. So if one fail and raise an exception, everything will be rollbacked.