0

some time ago I read an opinion about how to handle modifying the contents of a database through a dialog (I suspect it was here on SO, but I was not able to find the relevant question). There are two possibilities:

  1. start a transaction when showing the form, commit it on clicking OK and rollback on clicking Cancel.

  2. read the relevant data from the database and cache it, do the required changes on the cached data and then update the DB with this data on clicking OK.

I am using the latter approach since the original comment recommended doing so, but I can't remember the reasoning behind it. I am currently reconsidering it because caching all the data seems to me a bit superfluous. Any thoughts/links on this topic?

crypto_rsa
  • 341
  • 1
  • 12

1 Answers1

0

For keeping a transaction; if you start the transaction, then you are locking that row. If the user takes forever in making any edits, then this locks others out for an extended period of time. However, if your app requires this definitive locking, then this might be a good route to go. But, the other route of caching data could work also; I would suggest looking into a system where the user is notified of changes made while editing their data, or you could check the data again before allowing the update (prompting the user to reload their data and remake changes if it has changed). I would personally use your current approach because it allows greater parallel work, just make sure you are dealing with changes appropriately based on your business needs.

Justin Pihony
  • 66,056
  • 18
  • 147
  • 180
  • Thanks for the summary. Anyway, I found the discussion [here](http://stackoverflow.com/questions/1968437/are-long-living-transactions-acceptable). – crypto_rsa Mar 20 '12 at 08:57