On Thu, Jun 3, 2010 at 11:15 PM, Darren Duncan <dar...@darrenduncan.net>wrote:
> Richard Hipp wrote: > > On Sat, May 29, 2010 at 5:42 PM, Darren Duncan <dar...@darrenduncan.net > >wrote: > >> "3. Transactions that involve changes against multiple ATTACHed > >> databases are atomic for each individual database, but are not atomic > across all > >> databases as a set." > >> > >> I greatly hope that this limitation could go away. I consider that > >> SQLite's > >> ability to make multiple databases subject to a common transaction is > very > >> powerful, and I would even argue, essential. > > > > See http://www.julianbrowne.com/article/viewer/brewers-cap-theorem > > Thanks for the url; that was an interesting read. > > > The semantics of ATTACH imply Partition. In the new WAL design, readers > > never block, which is the same as Accessible. Hence, we must forgo > > cross-database atomic commits (what the CAP theorem calls "Consistent"). > > I believe that in SQLite's case, unless perhaps when some of the attached > databases are on different physical machines from each other or the main > one, > that CAP (you can have at most 2 of 3) isn't applicable, or that there are > some > common situations where it isn't applicable. (From my reading, CAP mainly > speaks to the situations where the database is split across multiple > physical > servers.) > Partition means that one part of the database cannot communicate with another part. In the usual use of the CAP theorem, this means that the database is spread across multiple machines and the network link is broken (or in practice, simply congested and sluggish). In the context of ATTACH it means that the two databases A.db and B.db cannot communicate with each other. Of course, they can communicate with each other since they are on the same machine, but they cannot communicate with each other in the context set up by the current implementation of ATTACH. ATTACH treats each attached database as a separate and independent entity. The key point for atomicity of commits is that each attached database has its own write-ahead log file and none of those separate write-ahead logs (WALs) know where to find any other. And so the WALs are effectively partitioned from one other, though by software design instead of by physical hardware limitations. So it seems we could fix this situation by somehow storing in each WAL information about the location of all the other WALs that participate in each transaction, thus removing the partition between the components of the aggregate database. -- --------------------- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
