Implementing transactions across threads without using J2EE

Discussions

Performance and scalability: Implementing transactions across threads without using J2EE

  1. I have a requirement wherein I can't use application server or a TP monitor or any other s/w that enables nested transaction .

    Requirement
    ===========
    1. Multiple threads are doing some processing. Each thread should be able to commit its portion.

    2. Finally after all the threads are done I should do a final commit.

    Solution
    ========
    1. A controller creats a connection object and creats prepared statement for each thread and passes it to respective threads. I am not doing any commit in each thread, just executing queries.

    2. Maintain a hashmap that keeps track of status of each thread and once all threads are done finally call commit on the connection object.


    Problem
    ======
    1. Since each thread is using the same underlying connection so this will be slow.

    2. JDBC limits me in the way I can implement transaction and it doesn't support nested transactions.


    Any ideas???
  2. Perhaps using a JDO implementation might solve your problem? Have a look at it, it's generally very good to use if you need ACID transactions (and persistence) without the overhead of a full J2EE implementation.

    On the other hand, it DOES use some kind of transaction monitor... (The PersistenceManager, that is.)

    Well, anyway, you only asked for ideas...

    Lars