Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is it possible to have a Java standalone application (no application server attached) that exposes some operations that a client can call and be the one to manage the transactions?

I was thinking this application to expose JNDI resources and get a hold of a java:comp/UserTransaction from there, get also a bean from there and call methods A, B and C on it and coordinate the transaction from the client?

The application I'm writing isn't complex enough so that I need a big application server around it so I'm thinking to have a standalone JTS inside it that the client could interact with from a transactions point of view.

I don't have much experience with distributed transactions and don't really know how to tackle the issue. Is it even possible? Am I getting myself into something beyond what a mere mortal (programmer) can handle?

How can I approach this?

share|improve this question
up vote 1 down vote accepted

Jboss and other application server vendors do offer a stand alone transaction manager that can be used stand-alone.

The JBoss Transaction Service (JBossTS) protects businesses from data corruption by guaranteeing complete, accurate business transactions for Java based applications (including those written for the JEE and EJB frameworks) thereby eliminating the risks and costs associated with time-consuming manual reconciliation following failures...

share|improve this answer
I think I'm gonna give this a try. Thanks! – johnny Jul 11 '12 at 9:48

Simple JNDI serving is straightforward, distributed transaction management is hard

There is a fairly comprehensive tutorial on JNDI provided by Oracle. Although it appears dated (JDK 1.1.2 anyone?) the JNDI specification has not changed a lot in the intervening time and is still relevant. Carefully reading through the examples will provide you with enough information to be able to construct a standalone application capable of serving up internal objects in response to JNDI requests.

Are you sure you need distributed transactions?

Your second question is to do with handling distributed transactions. There are several ways to interpret a distributed transaction based on the level of collaboration between applications.

In the simple case you'd have a workflow like this:

  1. Application A sends a work package to Application B over HTTP
  2. Application B attempts to commit this to the database. If successful a 200 OK is returned, otherwise some error code is used.
  3. Application A knows how to react to a failure appropriately.

Clearly you wouldn't need JNDI to implement this kind of workflow, other than perhaps to have your application (Application C) take the role of providing Application B with the database connection pool (Tip: use C3P0 for that).

In the complex case you'd have a workflow more like this:

  1. Application A registers the start of a distributed transaction with Application C, and then works with the database to do some work.
  2. Application A completes part of the overall transaction and hands over to Application B to finish it. Application A notifies Application C of the status.
  3. Application B registers its part of the transaction with Application C and attempts to complete its work. If it fails, Application C knows how to orchestrate the rollback (perhaps using nested transaction management).

If you're looking for a workflow like the complex case, then I'd say you should be considering an application container to manage it. If not, then you may not even need JNDI.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.