Path: news.easynews.com!core-easynews!newsfeed1.easynews.com!easynews.com!easynews!news-feed01.roc.ny.frontiernet.net!nntp.frontiernet.net!logbridge.uoregon.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail From: 71062.1056@compuserve.com (--CELKO--) Newsgroups: comp.databases.theory Subject: Re: Alternatives to ACID, non-serialized concurrent transactions? Date: 5 May 2003 09:24:25 -0700 Organization: http://groups.google.com/ Lines: 36 Message-ID: References: NNTP-Posting-Host: 68.26.10.207 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1052151865 10631 127.0.0.1 (5 May 2003 16:24:25 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 5 May 2003 16:24:25 GMT Xref: core-easynews comp.databases.theory:26178 X-Received-Date: Mon, 05 May 2003 09:23:55 MST (news.easynews.com) >> And, if ACID is not desirable, then, what alternatives might be so? << Several years ago Unisys had an internal project for what they called "logical concurrency control",which looked interesting, but I don't think it got out of the laboratory. The idea was to queue the actions against the database and see which ones shared data and which ones were disjoint. Queries do not change the data, but they might share it -- if (n) sessions want to access the same VIEW (say reports off of the same end of the month summary VIEW), then it is probably cheaper to materialize it once and hold it in main storage than to put the code into the FROM clauses of every query in every session. INSERT, UPDATE and DELETE do change the data, but they might not share it -- if session #1 works only with tables X and Y, and session #2 works only with tables W and Z, and there is no relationship via DRI, ASSERTIONs, etc. in those collections of tables, then sessions #1 and #2 can be in the database at the same. At a finer grandularity, if sessions #1 and #2 both work with tables X and Y, but not on the same subset of rows (as determined by their predicates), then sessions #1 and #2 can be in the same tables at the same time. They might be able to share only a subset of the tables -- say session #1 updates 'Men' and session #2 updates 'Women' in the Personnel table, but they can overlap in the HealthPlan table. At this point, you need serialization. There are scheduling problems that need to be solved so that every session gets to use the database, the overall work flow is optimal or near-optimal, etc. -- but we have a lot of years of experience and math from batch processing for that kind of task.