And close the previous transaction when a suitable granularity of focus changes, eg before a editable table gains input focus, a tab change , or another node of the tree is selected.
On Sat Oct 13 4:28 , Syan Tan sent: > >select for update just protects from having the transaction being aborted later >on, otherwise >it will block if someone else is updating. it doesn't address the issue of >having >client cached >values being changed outside of a transaction. holding one transaction only to >interactively update a complex object would be more headache due to cascading >abort, then just issuing an exclusive lock on all items related to the object ( >e.g by writing a lock into a lookup table against the object's id), which isnt >what's wanted. opening the transaction just before an update means each write >needs to be checked manually for a conflict, because the user only sees a >cached >old value, which might have changed because no transaction was open whilst the >user was browsing of the object. >It's probably to do with the complexity of the user interface structure; some >user interfaces only display one page of one view at the most , so that at >most >opening a transaction with each user page involves locking only a few rows of >one >or two tables, so it would make sense to do as below, but for an application >that >edits data for a complex obect composed of 10 or more tables, >it might not be sensible. >I suppose there's the answer then, open up a transaction every time the tab >page >is changed >or a tree node is selected, and select for update everything that is being >displayed and editable. > > > >On Fri Oct 12 20:49 , Richard Broersma Jr sent: > >>--- syan tan wrote: >>> What other ways are there of doing such an app? >> >>The two ways that I know of are: >> >>BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE; >> >>--if the tuple was modified by another transaction, this transaction will fail >on commit. >> >>SELECT FOR UPDATE... -- pre-lock the tuple of interest from other commits. >> >>Regards, >>Richard Broersma Jr. >> >>---------------------------(end of broadcast)--------------------------- >>TIP 7: You can help support the PostgreSQL project by donating at >> >> http://www.postgresql.org/about/donate > > > >---------------------------(end of broadcast)--------------------------- >TIP 7: You can help support the PostgreSQL project by donating at > > http://www.postgresql.org/about/donate _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
