Optimistic Locking with SAP JPA

[Former Member]

I'm getting

If this persistence unit shall run with isolation level TRANSACTION_READ_UNCOMMITTED,
 a database table for a version generator must be provided an the name of
 this table must be specified in the persistence.xml using the property 
com.sap.jpa.versioning.generator.tablename.

Can someone give me the CREATE TABLE statement for that // is the layout specified by JPA?

Thanks

[Former Member]

Well, actually it can solve your problem.

The EJB container "listens" for any exception, that your retriable business method may throw, and when it catches one, it investigates its entire cause chain. If it finds an exception which is present in the retryOn list, then the method will be retried.

What is somehow strange here, is your particular use case. In a usual situation, you cannot cope with DuplicateKeyException by a method retry, because this exception tells you that the DB state is trying to be violated. In a method retry, you can succeed only if you perform some deletion logic (in order to clean the table), maybe...

[Former Member]

In my case it does make sense ... I don't want to explain my whole use case, so just imagine a string pool in a database ... the business method tries to get the existing string to point another object to it and if it doesn't exist yet the string is created. With concurrency and a secondary key this might fail ...

[Former Member]

Well, why not ?

Actually, it depends on the way you organize your business logic. If you are able to locate the particualr business method that throws the DuplicateKeyException, then you should make it retriable for this exception, and that's all. Beware that the whole business method will be retried, so the logic in this method must be somehow "atomic", i mean that if it contains parts that you do not want to be retried, then you should probably need to design a new business method that encapsulates only the retriable parts.

[Former Member]

In fact, I'm now tackling the DuplicateKeyException problem on a lower level now. I'm creating the entities in a separate transaction.

The problem is that @Retriable wouldn't solve my problem, because the DuplicateKeyException is deeply nested within other Exceptions.

[Former Member]

Hi folks,

Actually starting from version 7.30, the SAP NetWeaver EJB container introduces a new functionality, i.e. the retriable business method concept. You can specify that a particular business method is retriable, either by annotating the method with the dedicated annotation @Retriable, or by using the additional deployment descriptor ejb-j2ee-engine.xml.

The example here

@Retriable(interval=0,maxAttempts=5,retryOn={OptimisticLockException.class})

public void myBusinessMethod() {

// ....

}

tells the container to retry the whole business method, maximum 5 times, if and only if OptimisticLockException is being thrown by the method, and waiting 0 milliseconds between the retry attempts. If the retriable method starts its own transaction (REQUIRES_NEW transaction attribute), then the method will be retried together with that transaction.

Via xml descriptor, here is how things look like :

<enterprise-bean>

<ejb-name>MyBean</ejb-name>

<retriable-methods>

<retriable-method>

<method-name>myBusinessMethod</method-name>

<retry-on>javax.persistence.OptimisticLockException</retry-on>

<max-attempts>5</max-attempts>

</retriable-method>

</retriable-methods>

</enterprise-bean>

This new feature is quite handy when it comes to OptimisticLockException, since, most of the times, this exception happens "just because of bad luck" and an immediate retry will most probably succeed. But, of course, you can make use of the feature for quite broad type of exceptions.

The retryOn attribute should be given a value that is a finite list of classes, they should all extend java.lang.Exception.

Please feel free to ask me about additional details if you need them!

Kindest Regards,

Krum.

[Former Member]

That's nice ... is there going to be a similar way for DuplicateKeyExceptions? My current solution is to go to the deepest cause in order to find out that there was a DuplicateKeyException, which is quite ugly

[Former Member]

Does Netweaver retry to invoke the business method when an OptimisticLockException occurs, or do I always have to introduce a UserTransaction to simulate this behavior.

Edited by: konrad.krentz on Jan 15, 2010 4:52 PM

[Former Member]

asdf

[Former Member]

Ok the table is generated automatically

But I have another related question:

Let's say I have a ManyToMany relationship and within a transaction only the join table is altered. Do I get optimistic lock exception then?

[adrian_goerler]

Hi Konrad,

we'll increase the version on the owning side. Let's say you have Book <-> Author and Book is the owning side.

If you concurrently change the authors of a book, you get an Optimistic Lock Exception. If you concurrently change the books written by an author, you won't.

-Adrian

[Former Member]

Is there a bug tracker - i just found one

[adrian_goerler]

Hi,

if you have access to OSS, please post your bug on BC-JAS-PER-JPA.

Otherwise, please post it here.

-Adrian

[former_member190457]

Hi Konrad,

I have the same problem.

I found no generated table whatsoever in my db.

could you please explain in more detail how you solved this?

Thanks, regards

Vincenzo

[adrian_goerler]

Hi all,

NetWeaver AS Java has a predefined system data source. Unless you are running on Oracle, the system data source has isolation level READ UNCOMMITTED. In order to use SAP JPA with isolation level READ UNCOMMITTED, a special version generator table has to be specified as described here. Additionally, you have got to specify the name of this version generator using the persistence unit property "com.sap.jpa.versioning.generator.tablename" as described here.

If you are using the tooling Dalí to generate database table, the version generator table should be generated as well, if you have specified the "com.sap.jpa.versioning.generator.tablename" property.

-Adrian