Atomic operations

dibblego · **Posted:** Fri Oct 22, 2004 1:03 am

Hibernate version: 2.0

Suppose I have an entity called 'Account' with a primary key field 'username'. Now, a user wants to create an 'Account' so they submit their preferred username, say "Fred".

How do I check if "Fred" exists, and if it doesn't, insert (Session.save) the Account?

For example, consider the following code:

Code:

tx = session.beginTransaction();

if(session.get(Account.class, "Fred") != null)
{
    tx.commit();
    // tell the user that this account username already exists
}
else
{
    Account a = new Account();
    session.save(a, "Fred");
    tx.commit();
}

I'm not sure how close this is to being correct, but I know that if two concurrent users are executing this code, there is potential for a race condition. If "Fred" doesn't exist, then user1 executes up to the point where the Account instance is created, then user2 executes, who also gets into the 'else block' - one of them will fail with a primary key violation.

So the question is, how do I achieve what I want to achieve - that is check if the account exists and if it doesn't, create that account; all in one atomic operation?

dibblego · **Posted:** Fri Oct 22, 2004 2:27 am

Another way to summarise my problem is "is it possible to obtain exclusive INSERT access on an entity?"

Lukasz (Qr) · **Joined:** Tue Sep 28, 2004 6:34 pm **Posts:** 50

You could lock the table, but I do not think that it is a good idea.

You can also try to catch the pk violation exception and if caught re-read:

Code:

        boolean caughtPKException = false;
        Session sess = factory.openSession();
        Transaction tx;
        try {
           tx = session.beginTransaction(); 
           if(session.get(Account.class, "Fred") == null) { 
              Account a = new Account(); 
              session.save(a, "Fred"); 
           } 
           tx.commit();
        } catch (??PK validation/duplicate /*
                                          * don't know exact name just insert
                                          * the same object twice to get it
                                          */??Exception e) {
            if (tx!=null) tx.rollback();
            caughtPKException = true;
        } finally {
            sess.close();
        }
       if (caughtPKException) {
          /*must obtain new session: [quote]If the Session throws an exception, the transaction must be rolled back and the session discarded. The internal state of the Session might not be consistent with the database after the exception occurs. [/quote]*/
           Session sess = factory.openSession();
           tx = session.beginTransaction(); 
           if(session.get(Account.class, "Fred") == null) { 
              //this should not happen 
           } 
           tx.commit();
       }

Diederich · **Joined:** Tue Jul 06, 2004 9:56 am **Posts:** 14

If your DB transaction level is serializable, your code should work out of the box, since your read and (possible) write operations are in the same transaction.

dibblego · **Posted:** Fri Oct 22, 2004 8:24 pm

Thanks for the reply.
I'm unsure what you mean by my "DB transaction level is serializable".
How can I tell? What document would I read to understand the concept?

I found the following code in the reference manual 9.2, which is exactly what I want, so it can't be too difficult to achieve in a concurrent environment.

I tried executing similar code from within a debugger using two concurrent users - after user1, I put a break within the statement block after the check for null. A subsequent execution of the code was also allowed to enter the statement block, which gave the idea that there needs to be some concurrency control - am I mistaken?

Code:

Cat cat = (Cat) sess.get(Cat.class, id);
if (cat==null) {
    cat = new Cat();
    sess.save(cat, id);
}
return cat;

[/code]

Lukasz (Qr) · **Joined:** Tue Sep 28, 2004 6:34 pm **Posts:** 50

A few things:

A)

Quote:

serialization at the transaction level - This means that every statement within a transaction will get the same consistent view of data as it existed at the start of the transaction.

B) you can use java's synchronized blocks to block threads

C) why do you want to use name as primary key - this seams wired - what if user changes name and you have relations with this pk?

Lukasz

dibblego · **Posted:** Fri Oct 22, 2004 9:21 pm

A)serialization at the transaction level - This means that every statement within a transaction will get the same consistent view of data as it existed at the start of the transaction.

Ok thanks - understood.

B) you can use java's synchronized blocks to block threads

Right - I assume this is what I want.

C) why do you want to use name as primary key - this seams wired - what if user changes name and you have relations with this pk?

An account is defined by the username. A user can delete an account or create a new one; the only alternative is to create an id for the Account entity and make username unique - which still has the same problem - but a user can change their username (if it doesn't exist), so it might be a better option.

Lukasz (Qr) · **Joined:** Tue Sep 28, 2004 6:34 pm **Posts:** 50

if you need something more related to user and unique than use email (it is more likely to be unique) and use integer as pk.

Lukasz