The feature to implement is to allow a user to select items and apply data update in bulk. It is very similar to JIRA's ability to bulk update a list of selected issues. In my case:
- I iterate over the items,
- and for each item, I simply call the existing method used for individually updating an item.
Take note, I cannot do this in sql level (ie. sql batch update) as business logic is in java.
Evidently, for performance, it will be slower given that a user decides to update multiple items, hence you can expect speed = # of items * rate of transaction. So in effect, updating an item individually should be same speed as bulk updating a list where the list contains a single item. That is fine, as it's a trade-off.
My other concern however is this: the method used to update individually, will remain unchanged, and will simply be called by bulk update multiple times according to the number of selected items; this method acquires locks to involved tables until it finishes its transaction. This in effect, would cause locking for long time if there were multiple items to be updated; hence a user would not be able to use the view and search page that retrieves from the locked tables. It's a trade-off that may not be as acceptable as the first point I discussed above.
I am conflicted, given that the nature of the existing method for individually updating an item is really to acquire locks, and I am not suppose to touch that code. I am supposed to only reuse that method, calling it multiple times to implement the bulk update. Is this 2nd trade-off something we cannot bypass, is it a valid trade-off?
Please note also, I am not an expert in transactions and locks.
