Drools JPA- Spring Transactions

What we do

We have a domain model. It is made up of a number of objects annotated with JPA annotations (for persistence) with Hibernate as the ORM provider.
The drools JPA persistence module is also made of java classes annotated for persistence.

We're trying to create a stateful session and start a process. Process stops in a waiting state at some point. Then we want to persist the session together with the process state. Application needs to be able to load the session back into memory and continue with the process execution (by sending notify events).

Issues

First issue
The first issue we faced was that the drools persistence module does not work out of box for Oracle.
Cause: Table/column names too long,
Fix: This was sorted by overrides to the annotations in the drools-jpa source code.

Current issue
The issues that we are currently facing are related to transactions/JPA entity manager and persisting of Session/Process/Workitem etc.
The expected transactional/persistence behaviour is

------- Begin Transaction (triggered by Spring's transactional annotation that also creates the entity manager)

1) Persist/Read domain entities from datasource
2) Persist/Read drools entities from same datasource

-------End Transaction (commit/rollback releases the entity manager)

The expected behaviour is without the use of a distributed transaction manager (because we have a single datasource and no distributed transactions)

It seems like the persistence module out of the box in drools-jpa relies on a Distributed transaction manager (DTM) and in the absence of one (configured by us) uses Bitronix (an built-in DTM)
The use of Bitronix further complicates matters as its not related to the transaction/entity manager created by Spring and visibility of domain entities/drools entities have of each other.

The way we would like to use drools persistence is:

a) Entities (drools/domain) to be managed by the same entity manager (persisted/read) for both Domain model entities and Drools JPA entities.
b) Participate in the same (RESOURCE_LOCAL) transaction (committed/rolled back)
c) Eliminate the need for a DTM if there is a single datasource

Question : is there anything we're doing is incorrect or is the described behaviour not available in the current version?

Any advice would be appreciated.