CODEWITHSUNDEEP
jpajpa-2.0transactionalspring-transactions
CodeChimp
CodeChimp

Reputation: 8154

Thoughts on high-concurrent entities and race conditions in JPA...Transactional?

I am working on a project, and have come to a sort of "design issue". I have an entity that represents a "Competition". Users are given votes, and they vote on the competition. Each competition has 10 items, and only 10 votes total can be cast on each. When a user tries to use their votes, I do a quick search for open competitions they haven't already voted on.

The problem comes when I think of multiple users all vying for the same competition. I don't care if two users are voting at once, but I want to prevent errors where a competition is recently closed, but there are still user(s) voting on it because they selected prior to closing...what I consider a "race condition" as the voting comes to a close.

The way I see it, there are only a few options:

Option 1: Turn on READ_COMMITTED transactions, but my understanding is that this locks the row on read, so no other queries will finish until the lock is returned. Since this is a JSP app, does the read lock end when the JSP is finished rendering? Seems like I could still have the same problem.

Option 2: Write out how many users have checked out the competition. This seems to follow the Database-as-IPC anti-pattern, though, and I could see where monitoring and maintaining the counts would be tricky at best.

Option 3: Dont worry about it. If the user takes too long voting, then just throw an error and make them move to the next one.

Option 4: Lean on AJAX heavily, maybe messaging using Atmosphere, to keep a live vote count on the competition page. Not sure how you handle browser timeouts or when the user simply leaves in the middle...perhaps some sort of cleanup timer?

Right now I am leaning on Option 4, as it seems to strike a nice balance between ease-of-implementation and ease-of-use from the user's perspective, but I want to be sure I am not missing any angles here.

How have others handled similar situations?

Upvotes: 0

Views: 197

Answers (1)

James
James

Reputation: 18379

You might consider using optimistic or pessimistic locking. That is the normal way to resolve concurrency issues.

Upvotes: 1

Related Questions