openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/optlockex/timestamp/TestTimestampOptLockEx.java

/*
 * Licensed to the Apache Software Foundation (ASF) under one
 * or more contributor license agreements.  See the NOTICE file
 * distributed with this work for additional information
 * regarding copyright ownership.  The ASF licenses this file
 * to you under the Apache License, Version 2.0 (the
 * "License"); you may not use this file except in compliance
 * with the License.  You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing,
 * software distributed under the License is distributed on an
 * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 * KIND, either express or implied.  See the License for the
 * specific language governing permissions and limitations
 * under the License.
 */
package org.apache.openjpa.persistence.optlockex.timestamp;

import javax.persistence.EntityManager;
import javax.persistence.EntityTransaction;

import org.apache.openjpa.persistence.test.SingleEMFTestCase;

/*
 * Test create for JIRA OPENJPA-2476, see it for a very detailed
 * description of the issue.
 */
public class TestTimestampOptLockEx extends SingleEMFTestCase {

    @Override
    public void setUp() {
        // By default we'd round a Timestamp to the nearest millisecond on Oracle (see DBDictionary.datePrecision
        // and DBDictionary.setTimestamp) and nearest microsecond on DB2 (see DB2Dictionary.datePrecision and
        // DBDictionary.setTimestamp) when sending the value to the db...if we change datePrecision to 1, we round to
        // the nearest nanosecond.  On DB2 and Oracle, it appears the default precision is microseconds but it seems
        // DB2 truncates (no rounding) to microsecond for anything it is given with greater precision, whereas Oracle
        // rounds.  So in the case of DB2, this test will pass if datePrecision=1, but still fails on Oracle.
        // On the other hand, if we set the datePrecision to 1000000 and run against DB2, the test will fail.

        // This test requires datePrecision to be set to the same precision as the Timestamp column.
        // I've only been testing on Oracle and DB2 and not sure how other DBs treat a Timestamps precision
        // by default.  In VersionTSEntity I use a Timestamp(3) but this is not supported on, at least, Derby
        // and older versions of DB2...at this time I'll enable only on Oracle.
        setSupportedDatabases(org.apache.openjpa.jdbc.sql.OracleDictionary.class);
        if (isTestsDisabled()) {
            return;
        }

        // Set datePrecision=1000000 for Oracle since we are using Timestamp(3)....on Oracle
        // the default is 1000000 so we shouldn't need to set it, but lets set it to future
        // proof the test.
        super.setUp(DROP_TABLES, "openjpa.jdbc.DBDictionary", "datePrecision=1000000", VersionTSEntity.class);
    }

    public void testUpdate() {
        poplulate();
        //This loop is necessary since we need a timestamp which has been rounded up
        //by the database, or by OpenJPA such that the in-memory version of the Timestamp
        //varies from that which is in the database.
        for (int i = 0; i < 5000; i++) {
            EntityManager em = emf.createEntityManager();
            EntityTransaction tx = em.getTransaction();

            // Find an existing VersionTSEntity:
            // stored with microsecond precision, e.g. 2014-01-21 13:16:46.595428
            VersionTSEntity t = em.find(VersionTSEntity.class, 1);

            tx.begin();
            t.setSomeInt(t.getSomeInt() + 1);
            t = em.merge(t);

            tx.commit();
            // If this clear is removed the test works fine.
            em.clear();

            // Lets say at this point the 'in-memory' timestamp is: 2014-01-22 07:22:11.548778567.  What we
            // actually sent to the DB (via the previous merge) is by default rounded (see DBDictionary.setTimestamp)
            // to the nearest millisecond on Oracle (see DBDictionary.datePrecision) and nearest microsecond on
            // DB2 (see DB2Dictionary.datePrecision) when sending the value to the db.
            // Therefore, what we actually send to the db is: 2014-01-22 07:22:11.548779 (for DB2) or
            // 2014-01-22 07:22:11.549 (for Oracle).  Notice in either case we rounded up.

            // now, do a merge with the unchanged entity
            tx = em.getTransaction();
            tx.begin();

            t = em.merge(t); // this results in a select of VersionTSEntity

            //This 'fixes' the issue (but customer doesn't really want to add this):
            //em.refresh(t);

            // Here is where things get interesting.....an error will happen here when the timestamp
            // has been rounded up, as I'll explain:
            // As part of this merge/commit, we select the timestamp from the db to get its value
            // (see method ColumnVersionStrategy.checkVersion below), i.e:
            // 'SELECT t0.updateTimestamp FROM VersionTSEntity t0 WHERE t0.id = ?'.
            // We then compare the 'in-memory' timestamp to that which we got back from the DB, i.e. on
            // DB2 we compare:
            // in-mem:  2014-01-22 07:22:11.548778567
            // from db: 2014-01-22 07:22:11.548779
            // Because these do not 'compare' properly (the db version is greater), we throw the OptimisticLockEx!!
            // For completeness, lets look at an example where the timestamp is as follows after the above
            // update: 2014-01-22 07:22:11.548771234.  We would send to DB2
            // the following value: 2014-01-22 07:22:11.548771.  Then, as part of the very last merge/commit, we'd
            // compare:
            // in-mem:  2014-01-22 07:22:11.548771234
            // from db: 2014-01-22 07:22:11.548771
            // These two would 'compare' properly (the db version is lesser), as such we would not throw an
            // OptLockEx and the test works fine.
            tx.commit();
            em.close();
        }
    }

    public void poplulate(){
        EntityManager em = emf.createEntityManager();
        EntityTransaction tx = em.getTransaction();
        tx.begin();
        VersionTSEntity r = new VersionTSEntity();

        r.setId(1L);
        r.setSomeInt(0);
        em.persist(r);
        tx.commit();
        em.close();
    }
}