Made this working when running in an application server and using JTA …

[ManuelB]

…transaction. This prevents the following:

16:49:38,901 ERROR [stderr] (default task-23) java.lang.IllegalStateException: Transaction is not accessible when using JTA with JPA-compliant transaction access enabled 16:49:38,913 ERROR [stderr] (default task-23) at org.hibernate@5.3.10.Final//org.hibernate.internal.AbstractSharedSessionContract.getTransaction(AbstractSharedSessionContract.java:405) 16:49:38,923 ERROR [stderr] (default task-23) at org.hibernate@5.3.10.Final//org.hibernate.internal.AbstractSessionImpl.getTransaction(AbstractSessionImpl.java:23) 16:49:38,933 ERROR [stderr] (default task-23) at org.jboss.as.jpa@17.0.0.Final//org.jboss.as.jpa.container.AbstractEntityManager.getTransaction(AbstractEntityManager.java:518) 16:49:38,943 ERROR [stderr] (default task-23) at deployment.appraisal-interview-backend.war//com.sap.olingo.jpa.processor.core.processor.JPACUDRequestProcessor.createEntity(JPACUDRequestProcessor.java:128) 16:49:38,957 ERROR [stderr] (default task-23) at deployment.appraisal-interview-backend.war//com.sap.olingo.jpa.processor.core.api.JPAODataRequestProcessor.createEntity(JPAODataRequestProcessor.java:77)

[CLAassistant]

All committers have signed the CLA.

[coveralls]

Pull Request Test Coverage Report for Build 54

• 53 of 79 (67.09%) changed or added relevant lines in 4 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.08%) to 73.626%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
jpa/odata-jpa-metadata/src/main/java/com/sap/olingo/jpa/metadata/core/edm/mapper/impl/JPATypeConvertor.java	8	16	50.0%
jpa/odata-jpa-processor/src/main/java/com/sap/olingo/jpa/processor/core/api/JPAODataBatchProcessor.java	9	18	50.0%
jpa/odata-jpa-processor/src/main/java/com/sap/olingo/jpa/processor/core/processor/JPACUDRequestProcessor.java	35	44	79.55%
<!--	Total:	53	79	67.09%	-->

Totals
Change from base Build 53:	-0.08%
Covered Lines:	7409
Relevant Lines:	10063

---

💛 - Coveralls

[wog48]

How about processing $batch requests? One can define multiple Change Sets and

All operations in a change set represent a single change unit so a service MUST successfully process and apply all the requests in the change set or else apply none of them.

See Part: 1 11.7.3 Change Sets

This requires that the JPA processor somehow has control over the transactions. How to adopt JPAODataBatchProcessor.processChangeSet?

[ManuelB]

Hi Oliver, when using JTA and EJBs every query in the same request are executed in the same transaction. Therefore this requirement should already be fulfilled.

Transaction control in an EJB container can be either controlled by the annotation TransactionAttribute:

https://docs.oracle.com/javaee/6/api/javax/ejb/TransactionAttribute.html

Or if you need more fine-grained control you can use bean managed transactions:

https://docs.oracle.com/javaee/6/tutorial/doc/bnciy.html

The annotation is:

@TransactionManagement(TransactionManagementType.BEAN)

The default is required. Without EJB and jta you have to create a lot of boilerplate code:

http://www.adam-bien.com/roller/abien/entry/jsf_jpa_ejb_bloat

Hope that helps

/Manuel

[wog48]

Hello Manuel,

thanks for supporting.

going back to my comment, JPAODataBatchProcessor method processChangeSet still needs to be adopted, otherwise requests like the once described in 3-6 Batch Requests will still fail with JTA. Any proposal?

[ManuelB]

@wog48 I implemented a solution that will only do the transaction handling if it is possible to get a transaction.

The cleanest way would be to Inject a UserTransaction and have two implementation a local one that delegates the calls to the entity manager and a JTA one that delegates the calls to a UserTransaction that is injected by the CDI container.

[wog48]

Guess transaction handling for $batch needs to be reworked to be able to handle various transaction manager.