Spring transaction issue with tomcat, mysql and eclipselink - mysql

Question

I've got lot of confusions after googling for spring transactions with eclipselink, tomcat and mysql. Please consider the following questions and guide me on this topic.
Can i run spring transactions with eclipseLink, tomcat and mysql enviornment? if so how is the config? i have used the following config and i get lock exceptions always.
Persistence.xml:
<persistence-unit name="xxxxService" transaction-type="RESOURCE_LOCAL">
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
<class>...</class>
<class>...</class>
<class>...</class>
<properties> .... </properties>
</persistence-unit>
Spring-beans.xml:
<bean id="jpaDialect" class="org.springframework.orm.jpa.vendor.EclipseLinkJpaDialect" />
<bean class="org.springframework.orm.jpa.JpaTransactionManager"
id="transactionManager">
<property name="entityManagerFactory" ref="entityManagerFactory" />
<property name="jpaDialect" ref="jpaDialect" />
</bean>
<bean id="jpaVendorAdapter"
class="org.springframework.orm.jpa.vendor.EclipseLinkJpaVendorAdapter">
<property name="showSql" value="true" />
<property name="generateDdl" value="true" />
<property name="databasePlatform" value="org.eclipse.persistence.platform.database.MySQLPlatform" />
</bean>
<bean
class="org.springframework.orm.jpa.LocalEntityManagerFactoryBean"
id="entityManagerFactory">
<property name="jpaVendorAdapter" ref="jpaVendorAdapter" />
<property name="jpaDialect" ref="jpaDialect" />
<property name="persistenceUnitName" value="xxxxService" />
</bean>
<tx:annotation-driven transaction-manager="transactionManager" />
<bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"/>
JAVA class:
#Transactional
public void saveSumthg(Sumthg sumthg) throws Exception{
someDAO.saveSumthg(sumthg);
}
#Transactional(propagation = Propagation.SUPPORTS, readOnly = true)
public List<Sumthg> findActiveSumthgs(String username) {
List<Sumthg> sumthgs = someDAO.findActiveSumthgs(username);
return sumthgs ;
}
Am i doing anything wrong here? I'm not sure whether spring transaction handling works correctly with tomcat since i'm not using JTA transactions.
With EclipseLInk and mysql, Id generation strategy goes with Sequence table and in the table only one row is updated for all transactions. I suspect that this causes lock issues. Am i correct? If so, how can i avoid this?
ID generation config in a Domain class is like this:
#Id
#Column(name = "some_id", unique = true, nullable = false)
#GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
In mysql schema, a new table named SEQUENCE is created and a value is stored in it. Each time when a row is inserted, the id is taken from here i think. Since the same value is read and updated, i suspect that this can cause locking issues.
If i'm correct, how can i avoid this issue??
Looking forward for your answers.
Thanks.
got an update - i can see the following is logs:
Internal Exception: java.sql.SQLException: Lock wait timeout exceeded; try restarting
transaction
Error Code: 1205
Call: UPDATE SEQUENCE SET SEQ_COUNT = SEQ_COUNT + ? WHERE SEQ_NAME = ?
bind => [50, SEQ_GEN]
Query: DataModifyQuery(name="SEQUENCE" sql="UPDATE SEQUENCE SET SEQ_COUNT =
SEQ_COUNT + ? WHERE SEQ_NAME = ?")]
So it is clear that this is happening because the same value in SEQUENCE table is being modified by several threads. What is the best ID generation strategy i can use in this context??

Answer 1

The problem is that you are using the worst concurrent ID GENERATION solution (TABLE_SECUENCE).
In this case the best solution is to use the SEQUENCE GENERATION.
The sequencers handle much better the concurrency.

Answer 2

I can't see how you would get lock exceptions always. Are you running multiple threads/clients? Try setting logging on finest to see what is going on.
EclipseLink will normally allocate sequence ids outside of the transaction, so would normally not have any locking conflicts. You can also enable a sequence connection pool in EclipseLink that will always use a seperate connection for allocating ids to avoid any locking conflicts.