Beauty Is in the Eye of the Beholder
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Atomikos TransactionsEssentials: JTA/XA transaction management outside of Java EE
Posted by Ryan Slobojan on Nov 15, 2007
Atomikos TransactionsEssentials, a Java-based transaction manager, just released version 3.2. InfoQ spoke with Atomikos CTO Guy Pardon to learn more about this release, and also about TransactionsEssentials and third-party transaction managers in general.
Pardon described the major features of TransactionsEssentials:
- JTA/XA transaction management - Transaction management and connection pooling are provided
- No application server required - TransactionsEssentials can be used inside of any Java EE application server, or independent of an application server
- Open Source - TransactionsEssentials is open source under the Apache license, version 2
- JDBC/JMS focus - Any XA resource is supported, and built-in resource pooling and message listening are provided for JDBC and JMS
- Spring and Hibernate integration - Documentation is provided which describes how to integrate with both Spring and Hibernate
Pardon also mentioned that Atomikos ExtremeTransactions was based upon TransactionsEssentials, and builds upon it by adding support for non-XA, compensation-based transactions and providing graphical administrative control panels for use in servlet containers. Atomikos also offers subscription-based support services, and a subscription grants access to the extra features in ExtremeTransactions.
When asked why one would want an external transaction manager, Pardon replied:
Let me turn the question around: why would you want an appserver?
Basically, the appserver has one big major productivity problem (besides being an old dinosaur): you have to deploy a packaged archive. This means that whatever you test before deployment is not complete. This also means that during deployment the risk that something goes wrong is high. This is a huge productivity problem IMHO.
Pardon also went on to say that, in many cases, an application server may not be the best solution for an application - he gave SOA/ESB endpoints as an example, stating that asynchronous JMS message handling and processing via JDBC could be done in a much more lightweight and scalable manner.
When asked about future releases of TransactionsEssentials, Pardon described greater JDBC and JMS connection pooling, OSGi support and JMX transaction administration as major features planned for version 3.3. Pardon also stated that adding JMX for the JDBC data sources and JMS connectors was a goal for version 4.0.
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
Configuring TransactionalEssentials with Spring/Hibernate
by
Matt Raible
Posted
Re: Configuring TransactionalEssentials with Spring/Hibernate
by
Guy Pardon
Posted
Re: Configuring TransactionalEssentials with Spring/Hibernate
by
Guy Pardon
Posted
Great to use during testing also
by
Jorg Heymans
Posted
Atomikos rocks
by
Martin Vanek
Posted
Full OSS Stack?
by
Daniel Gredler
Posted
g'night JOTM!
by
Dan Allen
Posted
Re: g'night JOTM!
by
Dan Allen
Posted
Re: g'night JOTM!
by
Mordechai Tamam
Posted
3.3 released by now...
by
Guy Pardon
Posted
-
FWIW, here's how to configure TransactionEssentials with Spring and Hibernate.
The Atomikos wiki has extra information here: wiki.atomikos.org/bin/view.pl/Main/HibernateInt... -
We use WeblogicJtaTransactionManager in our applications, but for out-of-container testing that involves JPA entities, XA datasource, JTA etc we rely on Atomikos. It requires no changes to the application other than injecting the Atomikos transaction manager and wrapped datasource. We had some problems during test execution (see [1]), but those were solved by putting <forkMode>pertest</forkMode> in the surefire configuration for maven2.
[1] www.atomikos-support.com/forums/viewtopic.php?t... -
Thanks to Atomikos we can run all functionality tests from main() with same result as in target appserver. So far (about 6 months) I didn't observed any differences and my development turnaround time has decreased greatly.
-
Atomikos is pretty nice. Now all that's left is for the PostgreSQL and MySQL people to get on the ball and fully support XA resources. They both support "most" of XA, and when you read about the limitations they sound minor, but in my experience you somehow always end up running into them.
PostgreSQL Limitations
MySQL Limitations -
I can say first hand that Atomikos is the way to go if you are looking for out-of-container XA-capable JTA transactions. I burned an entire weekend a while ago trying to get JOTM to do anything useful, but had absolutely no luck (but certainly less hair).
I then downloaded Atomikos and had it working in less than 30 minutes (I have no doubt others could do it faster). When I say working, I was able to get it to successfully rollback changes committed to one database after the commit to the second database failed, which is the fundamental value proposition of XA transactions.
Given that Atomikos is open source, what is not to like? I just hope I can save someone else the weekend. Kiss JOTM goodbye. -
I will say that the appserver bashing is not necessary. There are times when an appserver is appropriate, and there are times when it isn't. The statement that it is an old dinosaur is just as dated as the object of the comparison. Appservers, like JBoss 5 and Glassfish V2, are just as fast to start as "lightweight" containers.
I recommend Atomikos, but I won't discredit the tremendous capabilities of an appserver. You will know when it is the right time to use one over the other. Let your judgement guide you. Don't just boycott because someone told you to (e.g. the Monkeys, Bananas, and Water-spray Experiment). -
The above URL has been moved to: wiki.atomikos.org/Documentation/HibernateInt... -
Hi,
A quick follow-up: we (Atomikos) have just released version 3.3 hinted at in the above news post - with mostly the JDBC innovations (new pools and data sources, improved performance) and log4j support. The JMX and JMS features have been planned for the next major release: 3.4...
Guy -
Maybe you can help me...
As you did, I downloaded Atomikos, but, I am getting a NullPointerException when I am trying to persist an entity (I'm using JPA over Hibernate)whose id is annotated with @GeneratedValue, The entity looks like this:
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;
@Entity
@Table(name = "USERS")
public class User {
@Id
@GeneratedValue(strategy=GenerationType.AUTO)
public int id;
@Column(name = "NAME")
public String name;
public User() {
}
}
The Spring application context XML:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:tx="http://www.springframework.org/schema/tx"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:p="http://www.springframework.org/schema/p"
xsi:schemaLocation="http://www.springframework.org/schema/beans www.springframework.org/schema/beans/spring-bea...
www.springframework.org/schema/context www.springframework.org/schema/context/spring-c...
www.springframework.org/schema/tx www.springframework.org/schema/tx/spring-tx-3.0...">
<context:annotation-config />
<bean id="userTransactionService" class="com.atomikos.icatch.config.UserTransactionServiceImp" init-method="init" destroy-method="shutdownForce">
<constructor-arg>
<props>
<prop key="com.atomikos.icatch.service">com.atomikos.icatch.standalone.UserTransactionServiceFactory</prop>
</props>
</constructorarg>
<bean></bean>
<context:property-placeholder/>
<bean id="AtomikosTransactionManager" class="com.atomikos.icatch.jta.UserTransactionManager" init-method="init" destroy-method="close" depends-on="userTransactionService">
<!-- When close is called, should we force transactions to terminate or not? -->
<property name="forceShutdown" value="false" />
<!-- IMPORTANT: disable startup because the userTransactionService above does this -->
<property name="startupTransactionService" value="false"/>
<bean></bean>
<bean id="AtomikosUserTransaction" class="com.atomikos.icatch.jta.UserTransactionImp" depends-on="userTransactionService">
<property name="transactionTimeout" value="300" />
</bean>
<!---
Configure the Spring framework to use JTA transactions from Atomikos
-->
<bean id="jtaTransactionManager" class="org.springframework.transaction.jta.JtaTransactionManager" depends-on="userTransactionService">
<property name="transactionManager" ref="AtomikosTransactionManager" />
<property name="userTransaction" ref="AtomikosUserTransaction" />
</bean>
<bean id="mydatasource" class="com.atomikos.jdbc.AtomikosDataSourceBean" init-method="init" destroy-method="close">
<property name="uniqueResourceName" value="XADBMS" />
<property name="xaDataSourceClassName" value="com.mysql.jdbc.jdbc2.optional.MysqlXADataSource" />
<property name="xaProperties">
<props>
<prop key="user">root</prop>
<prop key="password">1234</prop>
<prop key="URL">jdbc:mysql://localhost:3306/test_transactions2</prop>
</props>
</property>
<property name="minPoolSize" value="1" />
<property name="maxPoolSize" value="50" />
</bean>
<bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean" >
<property name="configLocation" value="classpath:hibernate.cfg.xml" />
<qualifier value="sessionFactory"/>
<property name="configurationClass" value="org.hibernate.cfg.AnnotationConfiguration" />
<property name="dataSource" ref="mydatasource" />
<property name="hibernateProperties">
<props>
<prop key="hibernate.show_sql" >true</prop>
<prop key="hibernate.formate_sql">true</prop>
<!-- TRANSACTION_READ_UNCOMMITTED 1, TRANSACTION_READ_COMMITTED 2, TRANSACTION_REPEATABLE_READ 4, TRANSACTION_SERIALIZABLE 8 -->
<prop key="hibernate.connection.isolation">4</prop>
<prop key="hibernate.max_fetch_depth">3</prop>
<prop key="hibernate.dialect">org.hibernate.dialect.MySQL5InnoDBDialect</prop>
<prop key="hibernate.transaction.manager_lookup_class">com.atomikos.icatch.jta.hibernate3.TransactionManagerLookup</prop>
<prop key="hibernate.transaction.factory_class">com.atomikos.icatch.jta.hibernate3.AtomikosJTATransactionFactory</prop>
<prop key="hibernate.connection.release_mode">after_transaction</prop>
<prop key="hibernate.current_session_context_class">jta</prop>
<prop key="hibernate.connection.autocommit">true</prop>
<prop key="hibernate.c3p0.preferredTestQuery">SELECT 1</prop>
<prop key="hibernate.bytecode.provider">javassist</prop>
<props></props>
<property></property>
<bean></bean>
<bean id="hibernateTemplate" class="org.springframework.orm.hibernate3.HibernateTemplate">
<property name="sessionFactory" ref="sessionFactory" />
</bean>
<tx:annotation-driven transaction-manager="jtaTransactionManager" />
<bean id="appContextHolder" class="com.inneractive.testAtomikos.ApplicationContext" />
<context:component-scan base-package="com.inneractive.testAtomikos"/>
<beans></beans>
The DAO class:
@Repository
public class UsersDAO {
@Autowired
private HibernateTemplate template;
@Transactional()
public <T> T findById(Class<T> clazz,Integer id){
return (T) template.get(clazz, id);
}
@Transactional(propagation=Propagation.REQUIRED, readOnly=false)
public void save(User user){
template.persist(user);
}
}
Any ideas??
Regards.
</t></t></!--></props></property></bean></!---
></!--></!--></bean></constructor-arg></bean></beans></?xml>
10 comments
Watch Thread Reply