The Apache Jakarta Commons Community has released Commons Transaction 1.0.

Commons Transaction is a spin-off from Jakarta Slide and provides utility classes commonly used in transactional Java programming. Among them are locks, transactional Maps and transactional file access.

Download page:
http://jakarta.apache.org/commons/transaction/downloads.html

Project website:
http://jakarta.apache.org/commons/transaction/

Release notes:
http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons/transaction/RELEASE-NOTES.txt?rev=1.3

Congrats,

TransactionalMapWrapper assumes that passed wrapped map is not thread-safe so it uses Collections.synchronizedMap(wrapped) to synchronize it. Can you anyone please tell me why? If I want to make my ConcurrentHashMap instance transactional then TransactionalMapWrapper will add synchronization overhead which isn't necessary. I would suggest to assume that wrapped map is thread-safe and document this so that it is the user's responsibility to pass a thread-safe map to the constructor.

keep it up!
-talip

TransactionalMapWrapper assumes that passed wrapped map is not thread-safe so it uses Collections.synchronizedMap(wrapped) to synchronize it. Can you anyone please tell me why? If I want to make my ConcurrentHashMap instance transactional then TransactionalMapWrapper will add synchronization overhead which isn't necessary. I would suggest to assume that wrapped map is thread-safe and document this so that it is the user's responsibility to pass a thread-safe map to the constructor.

Good idea. Maybe using a instanceof check would be even more appropriate?

Oliver

TransactionalMapWrapper assumes that passed wrapped map is not thread-safe so it uses Collections.synchronizedMap(wrapped) to synchronize it. Can you anyone please tell me why? If I want to make my ConcurrentHashMap instance transactional then TransactionalMapWrapper will add synchronization overhead which isn't necessary. I would suggest to assume that wrapped map is thread-safe and document this so that it is the user's responsibility to pass a thread-safe map to the constructor.

Good idea. Maybe using a instanceof check would be even more appropriate?Oliver

No, class SynchronizedMap is private :( Still, the overhead should not be too much...

Oliver

Technical discussions should take place in the Commons mailing lists:

http://jakarta.apache.org/site/mail2.html#Commons

Oliver

Could we get some sample code of how to use this lib and in what scenarios it is going to be useful.

Is there an example code posted somewhere? Help would be appreciated.
Till now we have been using DB transaction control only, but this may be useful.

Could we get some sample code of how to use this lib and in what scenarios it is going to be useful.Is there an example code posted somewhere? Help would be appreciated.Till now we have been using DB transaction control only, but this may be useful.

There is a tutorial for locking including source fragments

http://jakarta.apache.org/commons/transaction/locks/tutorial.html

Transactional Map usage would be explained best in the API docs. The access to a transactional map is the same as to an ordinary map (same interface):
http://jakarta.apache.org/commons/transaction/apidocs/org/apache/commons/transaction/memory/TransactionalMapWrapper.html

HTH
Oliver

Congratulations!

I apologize in advance if this question does not belong to this forum. Can Commons Transaction be used with Lucene so we could have transaction support when creating/deleting indexes in the file system?

Regards,
Alex.

Congratulations!I apologize in advance if this question does not belong to this forum. Can Commons Transaction be used with Lucene so we could have transaction support when creating/deleting indexes in the file system?Regards,Alex.

To make lucene transactional aren't you going to need a recovery log?

Congratulations!I apologize in advance if this question does not belong to this forum. Can Commons Transaction be used with Lucene so we could have transaction support when creating/deleting indexes in the file system?

I have thought about exactly this as well. However, Commons Transaction can not be used to modify existing files. So, if you have on file for the indices, I suppose it will not work.

Oliver

Upgrade locks can help significantly increase concurrency (the idea is that only one thread can hold an upgrade lock, but while that is held, it is possible for read locks to exist and/or be obtained, and when the request is made to upgrade to a write lock in the same transaction, the lock manager prevents additional read locks until the write lock can be aquired).

Are there any plans to incorporate upgrade locks into a future release?

From glancing at the API it looks like the framework might support it, all that might need to be done is to implement a ReadWriteUpgradeLock implmentation similar to the existing ReadWriteLock

Upgrade locks can help significantly increase concurrency (the idea is that only one thread can hold an upgrade lock, but while that is held, it is possible for read locks to exist and/or be obtained, and when the request is made to upgrade to a write lock in the same transaction, the lock manager prevents additional read locks until the write lock can be aquired).Are there any plans to incorporate upgrade locks into a future release? From glancing at the API it looks like the framework might support it, all that might need to be done is to implement a ReadWriteUpgradeLock implmentation similar to the existing ReadWriteLock

I see. This sounds like a preference to a write lock, right? Anyway, this should be possbile. What are the scenarios in which concurrency is increased with such a lock?

Oliver

Upgrade locks can help significantly increase concurrency..

I see. This sounds like a preference to a write lock, right? Anyway, this should be possbile. What are the scenarios in which concurrency is increased with such a lock?Oliver

See the chapter on OCS in the CORBA manuals.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

What are the scenarios in which concurrency is increased with such a lock?Oliver

Whenever your writer has a significant phase of "preparation" before it actually starts writing. During that phase it behaves like a reader but has the additional garantuee that noone else is preparing concurrently.

Gruesse
Matthias

What are the scenarios in which concurrency is increased with such a lock?Oliver

Whenever your writer has a significant phase of "preparation" before it actually starts writing. During that phase it behaves like a reader but has the additional garantuee that noone else is preparing concurrently.GruesseMatthias

Hey, thanks for explaining, I have implemented this now and it will be part of the 1.1 release. There will be general preference locks as well...

Bis dann,

Oliver

Upgrade locks can help significantly increase concurrency (the idea is that only one thread can hold an upgrade lock, but while that is held, it is possible for read locks to exist and/or be obtained, and when the request is made to upgrade to a write lock in the same transaction, the lock manager prevents additional read locks until the write lock can be aquired).Are there any plans to incorporate upgrade locks into a future release? From glancing at the API it looks like the framework might support it, all that might need to be done is to implement a ReadWriteUpgradeLock implmentation similar to the existing ReadWriteLock

I have thought about it for a while and think this should not be too hard to do. I guess the 1.1 release can contain it. By the way the 1.0 version does not have deadlock detection, which already has been implemented for 1.1

Oliver

Hello,

Where are the examples?

I like to see an examples about file sequeence.

And,

How can i use transaction commons to wrap an tcp server
into a xa transaction?

How can i do it?

Thank you