29

I have several mapped objects in my JPA / Hibernate application. On the network I receive packets that represent updates to these objects, or may in fact represent new objects entirely.

I'd like to write a method like 

<T> T getOrCreate(Class<T> klass, Object primaryKey)

that returns an object of the provided class if one exists in the database with pk primaryKey, and otherwise creates a new object of that class, persists it and returns it.

The very next thing I'll do with the object will be to update all its fields, within a transaction.

Is there an idiomatic way to do this in JPA, or is there a better way to solve my problem?

HenryR
  • 7,719
  • 6
  • 32
  • 39

5 Answers5

21

I'd like to write a method like <T> T getOrCreate(Class<T> klass, Object primaryKey)

This won't be easy.

A naive approach would be to do something like this (assuming the method is running inside a transaction):

public <T> T findOrCreate(Class<T> entityClass, Object primaryKey) {
    T entity = em.find(entityClass, primaryKey);
    if ( entity != null ) {
        return entity;
    } else {
        try {
            entity = entityClass.newInstance();
            /* use more reflection to set the pk (probably need a base entity) */
            return entity;
        } catch ( Exception e ) {
            throw new RuntimeException(e);
        }
    }
}

But in a concurrent environment, this code could fail due to some race condition: 

T1: BEGIN TX;
T2: BEGIN TX;

T1: SELECT w/ id = 123; //returns null
T2: SELECT w/ id = 123; //returns null

T1: INSERT w/ id = 123;
T1: COMMIT; //row inserted

T2: INSERT w/ name = 123;
T2: COMMIT; //constraint violation

And if you are running multiple JVMs, synchronization won't help. And without acquiring a table lock (which is pretty horrible), I don't really see how you could solve this.

In such case, I wonder if it wouldn't be better to systematically insert first and handle a possible exception to perform a subsequent select (in a new transaction).

You should probably add some details regarding the mentioned constraints (multi-threading? distributed environment?).

Pascal Thivent
  • 549,808
  • 132
  • 1,049
  • 1,115
  • 1
    One answer I've had suggested to me for the multi-JVM case is to use cooperative advisory locks on the DB (e.g. http://www.postgresql.org/docs/9.1/static/explicit-locking.html). You lock the desired primary key, then do the check/update, then release the lock. – Matt R Mar 10 '14 at 10:49
  • That's interesting, @MattR, though I don't know if other database's provide a similar mechanism. It doesn't look like Oracle does. – DavidS Apr 12 '17 at 23:17
9

Using pure JPA one can solve this optimistically in a multi-threaded solution with nested entity managers (really we just need nested transactions but I don't think that is possible with pure JPA). Essentially one needs to create a micro-transaction that encapsulates the find-or-create operation. This performance won't be fantastic and isn't suitable for large batched creates but should be sufficient for most cases.

Prerequisites:

  • The entity must have a unique constraint violation that will fail if two instances are created
  • You have some kind of finder to find the entity (can find by primary key with EntityManager.find or by some query) we will refer to this as finder
  • You have some kind of factory method to create a new entity should the one you are looking for fail to exist, we will refer to this as factory.
  • I'm assuming that the given findOrCreate method would exist on some repository object and it is called in the context of an existing entity manager and an existing transaction.
  • If the transaction isolation level is serializable or snapshot this won't work. If the transaction is repeatable read then you must not have attempted to read the entity in the current transaction.
  • I'd recommend breaking the logic below into multiple methods for maintainability.

Code:

public <T> T findOrCreate(Supplier<T> finder, Supplier<T> factory) {
    EntityManager innerEntityManager = entityManagerFactory.createEntityManager();
    innerEntityManager.getTransaction().begin();
    try {
        //Try the naive find-or-create in our inner entity manager
        if(finder.get() == null) {
            T newInstance = factory.get();
            innerEntityManager.persist(newInstance);
        }
        innerEntityManager.getTransaction().commit();
    } catch (PersistenceException ex) {
        //This may be a unique constraint violation or it could be some
        //other issue.  We will attempt to determine which it is by trying
        //to find the entity.  Either way, our attempt failed and we
        //roll back the tx.
        innerEntityManager.getTransaction().rollback();
        T entity = finder.get();
        if(entity == null) {
            //Must have been some other issue
            throw ex;
        } else {
            //Either it was a unique constraint violation or we don't
            //care because someone else has succeeded
            return entity;
        }
    } catch (Throwable t) {
        innerEntityManager.getTransaction().rollback();
        throw t;
    } finally {
        innerEntityManager.close();
    }
    //If we didn't hit an exception then we successfully created it
    //in the inner transaction.  We now need to find the entity in
    //our outer transaction.
    return finder.get();
}
Pace
  • 38,293
  • 12
  • 111
  • 142
  • 2
    To reduce `finder` calls by 50%: `public static T findOrCreate( EntityManagerFactory emf, Supplier finder, Supplier factory) { EntityManager em=emf.createEntityManager(); T attempt1=finder.get(); if(attempt1 != null) return attempt1; T created=factory.get(); try { em.getTransaction().begin(); em.persist( created ); em.getTransaction().commit(); return finder.get(); } catch(Exception ex) { em.getTransaction().rollback(); T attempt2=finder.get(); if(attempt2!=null ) return attempt2; throw ex; } catch(Throwable t) { em.getTransaction().rollback(); throw t; } finally { em.close(); } }` – krevelen Sep 15 '16 at 13:55
  • @krevelen That is a good idea (it avoids more than just a read it avoids opening a transaction which can yield significant performance benefits) and will work if your isolation level is read committed or read uncommitted but will fail with repeatable read (default in many instances). Although I believe even my approach would fail if the isolation level is serializable. – Pace Sep 15 '16 at 15:37
2

I must point out there's some flaw in @gus an's answer. It could lead to an apparent problem in a concurrent situation. If there are 2 threads reading the count, they would both get 0 and then do the insertion. So duplicate rows created.

My suggestion here is to write your native query like the one below:

insert into af_label (content,previous_level_id,interval_begin,interval_end) 
    select "test",32,9,13
    from dual 
    where not exists (select * from af_label where previous_level_id=32 and interval_begin=9 and interval_end=13)

It's just like an optimistic lock in the program. But we make the db engine to decide and find the duplicates by your customized attributes.

E_net4 - Krabbe mit Hüten
  • 24,143
  • 12
  • 85
  • 121
Eason Du
  • 61
  • 4
0

How about use orElse function after findByKeyword? You can return a new instance if no record is found.

        SearchCount searchCount = searchCountRepository.findByKeyword(keyword)
                .orElse(SearchCount.builder()
                        .keyword(keyword)
                        .count(0)
                        .build()) ;
gus an
  • 1
0

There is an easy solution to have this tackled even in a concurrent environment.

Use optimistic locking on your entities with @Version private Long version; and <column name="version" type="BIGINT"/> in your liquibase table creation. If you try to save a new entity thats (composite) p_pkey already exists, a DataIntegrityViolationException will be thrown up to the JpaRepository. So there's no need to worry about concurrent locking in your service layer - the database will know if an entity exists.

Green Bud
  • 1