DummyTransactionManagerLookup, isolation level required for

[acruise]

Hi there,

I'm looking at using JBossCache for a quota system in which users are allowed to make a certain number of requests per hour, per day, etc., but it has to be cluster-wide. I'm already using JBossCache for another part of my application, so I'm familiar with the basics, but I have a few specific questions:

1) Is the DummyTransactionManager sufficient to do real "iron-clad" locking if I don't want to involve any other resources in my transactions? My application is deployed in Tomcat and is as lightweight as possible. If I can continue to avoid having a real distributed transaction manager, I'd like to do so.

2) I'd like to prevent dirty reads by multiple concurrent cluster nodes. For example, let's say a user has already used 99 of their allotment of 100 requests for today and submits two concurrent requests to two cluster nodes, somehow managing to bypass the load balancer. Node1 looks up the user's current counter, sees 99 and decides to allow the request, after incrementing the counter to 100 and committing its transaction. Node2 will try to do exactly the same thing, simultaneously. What isolation level do we need to use to ensure that Node2 either fails its read or sees 100, and delays or forbids the request?

Thanks!

[belaban]

1) No, don't use it for real stuff

2) SERIALIZABLE should do the job

[acruise]

1) No, don't use it for real stuff

2) SERIALIZABLE should do the job

Thanks for your quick reply. I'll have another look at implementing JTA under Tomcat. :)

[acruise]

1) No, don't use it for real stuff

So, just to be clear, you can't build a standalone (e.g. non-application-server) application that implements the atomic-increment functionality I'm looking for?

Or is it possible but would require dropping down to JGroups' explicit locking functionality rather than using a transaction API?

[belaban]

No, you can, but I'd suggest a different standalone transaction manager