Question

I’m looking for a high level answer, but here are some specifics in case it helps, I’m deploying a J2EE app to a cluster in WebLogic. There’s one Oracle database at the backend.

A normal flow of the app is
– users feed data (to be inserted as rows) to the app
– the app waits for the data to reach a certain size and does a batch insert into the database (only 1 commit)

There’s a constraint in the database preventing “duplicate” data insertions. If the app gets a constraint violation, it will have to rollback and re-insert one row at a time, so the duplicate rows can be “renamed” and inserted.

Suppose I had 2 running instances of the app. Each of the instances is about to insert 1000 rows. Even if there is only 1 duplicate, one instance will have to rollback and insert rows one by one.

I can easily see that it would be smarter to re-insert the non-conflicting 999 rows as a batch in this instance, but what if I had 3 running apps and the 999 rows also had a chance of duplicates?

So my question is this: is there a design pattern for this kind of situation?

This is a long question, so please let me know where to clarify. Thank you for your time.

EDIT:
The 1000 rows of data is in memory for each instance, but they cannot see the rows of each other. The only way they know if a row is a duplicate is when it’s inserted into the database.

And if the current application design doesn’t make sense, feel free to suggest better ways of tackling this problem. I would appreciate it very much.

Answer 1

http://www.oracle-developer.net/display.php?id=329