We Keep Coding

Transaction synchronization vs transaction association in JPA

I don't understand the difference between the concepts. Pro JPA 2 says the following:
Transaction synchronization is the process by which a persistence context is registered with a transaction so that the persistence context can be notified when a transaction commits. The provider uses this notification to ensure that a given persistence context is correctly flushed to the database.
Transaction association is the act of binding a persistence context to a transaction. You can also think of this as the active persistence
context within the scope of that transaction.
Could you please give some more explanation, maybe practical examples? Should I care about it in Java SE environment not using any JTA transactions? Thank you for any note!

Transaction Synchronization : You can think of this as Spring's TransactionSynchronization interface which receives callback for transaction synchronization..It has various methods like afterCommit(), afterCompletion(),beforeCommit() which get called as per transaction's state..Consider a practical example where you want to send an email to user once user registration is completed ,notify any external service depending on transaction state or log any particular event..
Transaction association:we basically commit transaction under active persistence context..let it be JPA's Entity manager or Hibernate's session..
Should I care about it in Java SE environment not using any JTA transactions?Yes..you will have to fall back to JDBC transaction demarcation..

Session is closed before concluding request in Spring MVC, get LazyInitializationException

I am taking the LazyInitializationException error when because in myController when I read the Lazy collections session is already closed. Is there any way to get it open as long as there is a request? As OpenSessionInView? What would be the best way?
I'm using the version of Spring Boot 1.3.0

You need use the "open session in view" to keep the session open after the end of the transaction.
see OpenSessionInViewFilter or OpenEntityManagerInViewFilter for JPA
imho it's better than extending the scope of the transaction to your controller.

If you're using a jackson/hibernate combination you can register the jackson-datatype-hibernate module, and tweak the Feature.FORCE_LAZY_LOADING property to your liking. The default is false means that only already fetched properties will be serialized. Changing to true will force initialization of the lazy properties

Java Batch(JSR-352) and Session Context CDI

I am using the java Batch (JSR-352), it is possible to work with a session bean inside it? I needed to have a Bean with #SessionScope annotation, to catch some information in it, that to differentiate the type of User that is running the batch process.
It's possivel use a Session Context CDI inside the specification ? If is possible how is the best pratice

In general, the session isn't going to propagate from the thread starting the job via JobOperator to the execution thread. I don't recall if this is under discussion in the CDI specification still or a settled matter, but for now you can't.

Open Session in View vs #Transactional

I had been using #Transactional annotations in my Service Layer. But to resolve an error due to Lazy Loading in View I had to use Open Session in View Filter. After this, without use of #Transaction itself a Session gets opened and transaction starts. So does that mean #Transactions are not required? How will transactions and roll-backs be handled, then in Service Layers?

The javadoc explains it:
This filter makes Hibernate Sessions available via the current thread, which will be autodetected by transaction managers. It is suitable for service layer transactions via HibernateTransactionManager or JtaTransactionManager as well as for non-transactional execution (if configured appropriately).
NOTE: This filter will by default not flush the Hibernate Session, with the flush mode set to FlushMode.NEVER. It assumes to be used in combination with service layer transactions that care for the flushing: The active transaction manager will temporarily change the flush mode to FlushMode.AUTO during a read-write transaction, with the flush mode reset to FlushMode.NEVER at the end of each transaction. If you intend to use this filter without transactions, consider changing the default flush mode (through the "flushMode" property).

JPA issue on Websphere -- works fine on Tomcat

I have a Spring 3 application using openJPA as persistence management, following section works fine in STS/Tomcat
#Transactional
createBalance(){
.....
Balance balance = new SummaryBalance();
balance.setName(name);
balance.setCurrency(currency);
balance.setClosingTimestamp(closingTime);
balance.setStatus(BalanceStatus.OPEN);
balance.persist(); // persist !!
......
balance.setCloseAmount(amount);
balance.setLastUpdateTimestamp(now);
}
However, when deploying same code in websphere 7, the closeAmount and lastUpdate does not update(both fields in DB didn't get update but from log both field can return values by their getter) then show up as null, but changes to other fields before persist() do take effect when the method finished. So I bet when the method finishing WS didn't flush the changes towards these fields.
I thought the JPA(regardless of vendor) should keep the balance entity object managed after persist() and flush the object after the method is finished with later changes. Turns out Websphere 7 doesn't make it. Even I put a merge() method
balance.setCloseAmount(amount);
balance.setLastUpdateTimestamp(now);
balance.merge();
still does not help.
Questions:
OpenJPA has already been included as dependencies in the deployment, but why still websphere need to involve with the JPA management?
How to solve the problem?
Thanks in advance.

I'm not sure that this exactly answers your question, but I think you should do some reconfiguration to use WebSphere capabilities, please check Spring 3.1 documentation
11.8.1 IBM WebSphere
On WebSphere 6.1.0.9 and above, the recommended Spring JTA transaction
manager to use is WebSphereUowTransactionManager. This special adapter
leverages IBM's UOWManager API, which is available in WebSphere
Application Server 6.0.2.19 and later and 6.1.0.9 and later. With this
adapter, Spring-driven transaction suspension (suspend/resume as
initiated by PROPAGATION_REQUIRES_NEW) is officially supported by IBM!
and
11.9.1 Use of the wrong transaction manager for a specific DataSource
Use the correct PlatformTransactionManager implementation based on
your choice of transactional technologies and requirements. Used
properly, the Spring Framework merely provides a straightforward and
portable abstraction. If you are using global transactions, you must
use the org.springframework.transaction.jta.JtaTransactionManager
class (or an application server-specific subclass of it) for all your
transactional operations. Otherwise the transaction infrastructure
attempts to perform local transactions on resources such as container
DataSource instances. Such local transactions do not make sense, and a
good application server treats them as errors.

Figure out a solution myself with guess work. Simply just place the persist() by the end of the whole method body.
#Transactional
createBalance(){
.....
Balance balance = new SummaryBalance();
balance.setName(name);
balance.setCurrency(currency);
balance.setClosingTimestamp(closingTime);
balance.setStatus(BalanceStatus.OPEN);
......
balance.setCloseAmount(amount);
balance.setLastUpdateTimestamp(now);
......
balance.persist(); // persist !!
}
That can make sure every fields are set before the method finished.
Both merge() and explicit flush() won't do the job but only with above compromise. Still not quite sure about the official work around....
I will keep this thread open for any new thinking come in :)