JDO Query inside transactions: yes or no?

Question

I've always used transactions when querying the database, but recently i wondered why.

What are the benefits / drawbacks of using / not using transactions on a "read-only" query?

Transactional:

public int count() {

    PersistenceManager pm=pmf.getPersistenceManager();
    JDOTransaction tx=(JDOTransaction)pm.currentTransaction();

    try{
        tx.begin();
        Query query=pm.newQuery(class);
        query.setResult("count(this)");
        Long count=(Long)query.execute();
        query.closeAll();
        tx.commit();

        return count.intValue();

    }finally{
        if (tx.isActive()) tx.rollback();
        pm.close();
    }
}

Non-transactional:

public int count() {

    PersistenceManager pm=pmf.getPersistenceManager();

    try{
        Query query=pm.newQuery(class);
        query.setResult("count(this)");
        Long count=(Long)query.execute();
        query.closeAll();

        return count.intValue();

    }finally{
        pm.close();
    }
}

What puzzles me is, for example, Datanucleus JDO implementation. if transactions do not lock the objects by default, what's the benefit of such transaction?

From the docs: JDOQL allows control over whether objects found by a query are locked during that transaction so that other transactions can't update them in the meantime: http://www.datanucleus.org/products/accessplatform_2_1/jdo/jdoql.html

Why would a JDO implementation default to locking all objects? That would be a recipe for deadlocks. From what I see JDO allows you to lock individual requests (a query, or a find), which is what makes sense. — Neil Stockton, Jun 09 '14 at 07:41
Yes, i agree! But you did not answer my question: what's the benefit of such "default" transaction? — marcolopes, Jun 09 '14 at 13:43
why would i answer your question if i put a comment? Answers go below. Besides the answer also answers that : transactions provide isolation, so dependent on isolation level the query doesn't see what is changing in other threads. — Neil Stockton, Jun 09 '14 at 18:32
My confusion comes from the fact that i can define a global transaction level (read-uncommitted | read-committed | repeatable-read | serializable) but then i can also specify properties like "transaction.serializeReadObjects" per transaction. I'm also confused with global properties like "datanucleus.rdbms.query.useUpdateLock" - isn't this the same as defining the global transaction level as "serializable"? (i understand these are DN specific properties, but nonetheless, JDO related) — marcolopes, Jun 10 '14 at 13:37
This question gives a light on the subject: http://stackoverflow.com/questions/7421314/some-clarifications-on-different-isolation-level-in-database-transaction — marcolopes, Jun 10 '14 at 14:26

score 2 · Accepted Answer · answered Jun 07 '14 at 18:43

2

That depends. If you have only an atomic read they are probably not needed.

However, If you want to read more than one value, possibly from different tables, possibly the choice depends on the result of the first query, transactions might help you: You might not want that the database changes while you perform your read-only query. Transactions can provide isolation, such as guaranteeing that the data does not change during the transaction.

To also mention drawbacks: Transactions are a performance hit.

answered Jun 07 '14 at 18:43

Fabian

363
2
6

What puzzles me is, for example, Datanucleus JDO implementation. if transactions do not lock the objects by default, what's the benefit of such transaction? (NOTE: See edited question) – marcolopes Jun 09 '14 at 04:22
1

As already mentioned in comments above: Lock everything by default is most of the time a bad idea. I do not know Datanucleus and can not tell you details of how to lock objects there. If you do not care about changing data I think transactions are not needed. The overhead should be pretty small in this case though. – Fabian Jun 10 '14 at 19:43

JDO Query inside transactions: yes or no?

1 Answers1