java - EJB/JPA Transaction Boundaries -

i reading ejb transaction boundary , transaction boundary

lets concentrate on requiresnew attribute.

here modified diagram link

so let method-b annotated requirednew attribute.

so according theory when method-a calls method-b new transaction start , started transaction suspended, , when method-b returns new transaction committed.

---

now consider in section s1 create jpa entity using entitymanager.persist() , pass entity method-b set name field of entity.

now when return method-b how can commit transaction in db, entity not being committed suspended transaction started method-a ?

---

ps: db running in read-committed isolation level.

what happens in scenario governed by:

1. the jpa persistence context , relationship jta transactions.
2. the behaviour of java’s “pass-by-reference” like parameter passing on local interfaces. (see note on pass-by-reference @ end of answer)

creating entity manager @persistencecontext annotation leads creation of transaction-scoped entity manager , associated persistence context defined persistence.xml file. context keep track of entities of types specified in persistence.xml. entity becomes managed in context after persisted, found (em.find()) or merged. context associated running jta transaction. when transaction ends, changes present in persistence context can flushed , committed - or rolled-back if transaction rolls back.

in example scenario assume bean2’s local interface used. when bean2-methodb called new transaction started since method annotated @transactionattribute(transactionattributetype.requires_new). transaction of calling method suspended. no persistence context associated newly created transaction. however, entity passed in refer same instance of entity processed bean1-methoda, , instance managed entity in persistence context of bean1’s entity manager. so, though transaction associated persistence context suspended, there no restrictions on modifying entity within transaction.

so, nominal sequence of events is;

1. bean1-methoda called, transactiona starts.
2. transaction-scoped entity manager created, persistence context associated transactiona.
3. bean1-methoda calls bean2methodb , passes in ’entity’ parameter.
4. new transaction – transactionb starts, transactiona suspended.
5. bean2-methodb modifies field entity.name.
6. bean2-methodb finishes , transactionb commits.
7. transactionb jta persistent resources commit - entity in persistence context associated transactiona , not committed.
8. bean1-methoda resumes associated transactiona.
9. entity changes made in bean2-methodb visible bean1-methoda , persistence context
10. bean1-methoda finishes, transactiona commits , persistence context changes flushed/committed db
11. --> db contains field change made in bean2-methodb

what happens when bean2-mehodb’s transaction rolls-back?

it worth noting if entity field changes made in bean2-methodb, , bean2-methodb’s transaction rolls-back, changes class fields not reverted. jta resources rolled-back, entity field changes still reflected in db if bean1-mehoda completes successfully, leading potential inconsistencies. maybe real world problems might force such solution, better modify entities in transaction can roll changes back.

the above scenarios tested on eclipse-mars/wildfly8.2/hibernatejpa/derby

working remote ejb calls

here, entity parameter serialised resulting in copy of entity in bean2-methodb. copy not same object used in bean1-methoda, detached entity , not shared bean1-methoda. (this known pass-by-value, see note @ end of answer). in order changes reflected in bean1-methoda’s persistence context entity need returned bean1-methoda , merged persistence context using entity manager. merging required regardless of whether or not remote ejb call made within transaction.

note on “pass-by-reference” , “pass-by-value”.

all parameters in java pass value definition. - extended - discussion on stack overflow see is java "pass-by-reference" or "pass-by-value"?. what’s important here local interfaces, java passes copy of reference – pointer - shared instance – , people understand “pass-by-reference”. remote interfaces create copy of entity instance @ remote end calling method has no visibility of changes copy. known pass-by-value.