You are currently browsing the daily archive for October 30, 2006.
Recently many people posted lots of interview skills, so I collected them here if you are an interviewer or interviewee.
1. The Guerrilla Guide to Interviewing (version 3.0)
2. How-to interview Java coder
3. Google Interview Questions (They Are Hiring)
4. The Best Tech Interview Question?
5. The tech side: Developer Job Interview Questions and Answers
6. Interview questions for tech companies
7. Interview Guide
This blog is to compare the transaction management of EJB 1.2 and Spring 1.2. Transaction is very important on J2EE environment and usually we don’t notice them because J2EE container or POJOs lightweight framework do help our dirty work.
What Is a Transaction? [J2EE 1.4 tutorial]
Transaction management [Spring 1.2 documents]
Nuts and Bolts of Transaction Processing
J2EE Transaction Frameworks:
Part I: Building the Framework
Part II:Distributed Transaction Primer
Part I: An introduction to transactions
Part II: The magic behind the scenes
Part III: Balancing safety and performance
2. Container-Managed Transactions(EJB 2.1) vs. Spring’s Declarative Transaction management(Spring 1.2):
EJB’s Transaction attribute:
Spring’s Progagation behavior:
EJB’s Isolation level:
Spring’s Isolation level:
Rolling Back a Container-Managed Transaction
There are two ways to roll back a container-managed transaction.
First, if a system exception is thrown, the container will automatically roll back the transaction. Second, by invoking the setRollbackOnly method of the EJBContext interface, the bean method instructs the container to roll back the transaction. If the bean throws an application exception, the rollback is not automatic but can be initiated by a call to setRollbackOnly.
Spring’s Roll back rules
Transaction can be declared to roll back or not based on exceptions that are thrown during the course of the transaction.
By default, transactions are rolled back only on runtime exceptions and not on checked exceptions.
3. Bean-Managed Transactions(EJB 2.1) vs. Spring’s Programmatic Transaction management(Spring 1.2):
In a bean-managed transaction, the code in the session or message-driven bean explicitly marks the boundaries of the transaction. An entity bean cannot have bean-managed transactions; it must use container-managed transactions instead.
Although beans with container-managed transactions require less coding, they have one limitation: When a method is executing, it can be associated with either a single transaction or no transaction at all. If this limitation will make coding your bean difficult, you should consider using bean-managed transactions.
Spring provides two means of programmatic transaction management:
– Using the TransactionTemplate
– Using a PlatformTransactionManager implementation directly
We generally recommend the first approach. The second approach is similar to using the JTA UserTransaction API.
<!– A minimal session EJB deployment –>
<!– or Stateless –>
<!– OPTIONAL, can be many. How the container is to manage
transactions when calling anEJB’s business methods –>
<!– Can specify many methods at once here –>
<!– NotSupported|Supports|Required|RequiresNew|Mandatory|Never –>
<property name=”transactionManager” ref=”txManager”/>
<property name=”target” ref=”petStoreTarget”/>
5. The following are the key differences from EJB CMT (from Introduce the Spring Framework)
a. Transaction management can be applied to any POJO. We recommend that business objects implement interfaces, but this is a matter of good programming practice, and is not enforced by the framework.
b. Programmatic rollback can be achieved within a transactional POJO through using the Spring transaction API. We provide static methods for this, using ThreadLocal variables, so you don’t need to propagate a context object such as an EJBContext to ensure rollback.
c. You can define rollback rules declaratively. Whereas EJB will not automatically roll back a transaction on an uncaught application exception (only on unchecked exceptions, other types of Throwable and “system” exceptions), application developers often want a transaction to roll back on any exception. Spring transaction management allows you to specify declaratively which exceptions and subclasses should cause automatic rollback. Default behaviour is as with EJB, but you can specify automatic rollback on checked, as well as unchecked exceptions. This has the important benefit of minimizing the need for programmatic rollback, which creates a dependence on the Spring transaction API (as EJB programmatic rollback does on the EJBContext).
d. Because the underlying Spring transaction abstraction supports savepoints if they are supported by the underlying transaction infrastructure, Spring’s declarative transaction management can support nested transactions, in addition to the propagation modes specified by EJB CMT (which Spring supports with identical semantics to EJB). Thus, for example, if you have doing JDBC operations on Oracle, you can use declarative nested transactions using Spring.
e. Transaction management is not tied to JTA.
Book: Spring in action: chapter 5. Managing transactions
Java Transaction Design Strategies
JOTM Transactions In Spring And Hibernate
Specify custom isolation levels with the Spring framework
Implementing Transaction Suspension in Spring
XA transactions using Spring
update of 11-02-2007
Understand database transaction isolation levels