java.lang.IllegalMonitorStateException: attempt to unlock read lock, not locked by current thread
at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.unmatchedUnlockException(Unknown Source)
at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(Unknown Source)
at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(Unknown Source)
at com.haulmont.cuba.core.app.SequencesImpl.getResult(SequencesImpl.java:152)
at com.haulmont.cuba.core.app.SequencesImpl.createNextValue(SequencesImpl.java:62)
at com.haulmont.cuba.core.app.UniqueNumbers.getNextNumber(UniqueNumbers.java:41)
at com.haulmont.cuba.core.app.UniqueNumbersServiceBean.getNextNumber(UniqueNumbersServiceBean.java:33)
The problem only happen using SQL Server +2012 (property cuba.dbmsVersion = 2012). I found that if I comment this property out, it works fine.If I create a new sequence with another identifier, it works well.
It seems that the sequence number was persisted first in its own table SEQ_UN_BATCH but then, when I put later on the 2012 property, it uses another way to persist the unique number (sys.sequence), maybe the problem is there, the mess with the two mechanisms at the same time ?
I set eclipselink.sql log to debug, check at line no.2198, you can see there the use of sys.sequence.
I think the problem with index creation.
Try to open MS SQL Management Studio, login with user (same as for CUBA application), execute SQL queries and check queries on errors:
select NAME from SYS.SEQUENCES where NAME = 'SEQ_UN_BATCH1';
create sequence SEQ_UN_BATCH1 as bigint increment by 1 start with 1 minvalue 0;