Why JPA Entity select result changes on each even query?

Question

My question is related to strange read/select behavior when same query returns different results after each call. Description of my situation is written below:

I have the following code, returning list of documents from DB

@RequestMapping(value={"/docs"}, method = RequestMethod.GET)
    @ResponseBody
    public ArrayList<Document> getMetaData(ModelMap modelMap) {
        return (ArrayList<Document>)documentDAO.getDocuments();
    }

DocumentDAO.getDocuments looks like

public List<Document> getDocuments() {
        Query query = entityManager.createQuery("from Document");
        List<Document> list = query.getResultList();
        for(Document doc:list) System.out.println(doc.getName()+" "+doc.isSigned());
        return list;
}

In other controller, I'm also extracting Document and changing boolean property with

 Document doc = documentDAO.getDocumentById(id)
 doc.setSigned(true);
 documentDAO.updateDocument(doc); // IS IT NECESSARY??

getById and updateDocument are the following:

public Document getDocumentById(Long id) {
        return entityManager.find(Document.class, id);
 }

@Transactional
public void updateDocument(Document document) {
    entityManager.merge(document);
    entityManager.flush();
}

Questions:

1. As far as I know, setting property of managed object is enough to propagate changes to DB. But I want to flush changes immediately. Is my approach with extra call of update is appropriate solution or calling setter is enough for making immediate changes in DB? By extra update I mean documentDAO.updateDocument(doc); // IS IT NECESSARY??
2. How JPA stores managed objects - in some internal data structure or simply keeps them in references like Document doc;? Internal structure most likely makes duplicate/sameID managed object impossible, references most likely makes possible to have multiple managed objects with same id and other properties.
3. How merge works internally - tries to find managed object with the same ID in internal storage and, in the case of detecting, refreshes it's fields or simply updates DB?
4. If internal storage really exists (most likely this is persistence context, futher PC), what is criteria for distinquish managed objects? @Id annotated field of hibernate model?

My main problem is different results of entityManager.createQuery("from Document");

System.out.println(doc.getName()+" "+doc.isSigned()); shows isSigned true on odd calls and false on even calls.

I suspect that first select-all-query returns entities with isSigned=false and put them to PC, after that user performs some operation which grabs entity byID, sets isSigned=true and just extracted entity conflicts with already presented in PC. First object has isSigned=false, second has isSigned=true and PC confused and returns different managed objects in rotation. But how its possible? In my mind, PC has mechanisms to not allow such confusing ambigious situations by keeping only one managed object for each unique id.

Answer 1

First of all you want to enrol both the read and the write in a single transactional service method:

@Transactional
public void signDocument(Long id) {
    Document doc = documentDAO.getDocumentById(id)
    doc.setSigned(true);
}

So this code should reside on the Service side, not in your web Controller.

1. As far as I know, setting property of managed object is enough to propagate changes to DB. But I want to flush changes immediately. Is my approach with extra call of update is appropriate solution or calling setter is enough for making immediate changes in DB? By extra update I mean documentDAO.updateDocument(doc); // IS IT NECESSARY??

This applies only to managed entities, as long as the Persistence Context is still open. That's why you need a transactional service method instead.

2. How JPA stores managed objects - in some internal data structure or simply keeps them in references like Document doc;? Internal structure most likely makes duplicate/sameID managed object impossible, references most likely makes possible to have multiple managed objects with same id and other properties.

The JPA 1st level cache simply stores entities as they are, it doesn't use any other data representation. In a Persistence Context you can have one and only one entity representation (Class and Identifier). In the context of a JPA Persistence Context, the managed entity equality is the same with entity identity.

How merge works internally - tries to find managed object with the same ID in internal storage and, in the case of detecting, refreshes it's fields or simply updates DB?

The merge operation makes sense for reattaching detached entities. A managed entity state is automatically synchronized with the database during flush-time. The automatic dirty checking mechanism takes care of this.

4. If internal storage really exists (most likely this is persistence context, further PC), what is criteria for distinguish managed objects? @Id annotated field of hibernate model?

The PersistenceContext is a session-level cache. The managed objects always have an identifier and an associated database row.

I suspect that first select-all-query returns entities with isSigned=false and put them to PC, after that user performs some operation which grabs entity byID, sets isSigned=true and just extracted entity conflicts with already presented in PC.

In the same Persistence Context scope this can't ever happen. If you load an entity through a query, the entity gets caches in the 1st level cache. If you try to load it again with another query or with the EntityManager.find() you will still get the same object reference, that's already cached.

If the first query happens against a Persistence Context and the second query/find will be issued on a second Persistence Context, then each Persistence Context will have to cache its own version of the entities being queried.

First object has isSigned=false, second has isSigned=true and PC confused and returns different managed objects in rotation. But how its possible?

This can't happen. The Persistence Context always maintains entity object integrity.