{"action":"created","issue":{"url":"https://api.github.com/repos/zodb/relstorage/issues/170","repository_url":"https://api.github.com/repos/zodb/relstorage","labels_url":"https://api.github.com/repos/zodb/relstorage/issues/170/labels{/name}","comments_url":"https://api.github.com/repos/zodb/relstorage/issues/170/comments","events_url":"https://api.github.com/repos/zodb/relstorage/issues/170/events","html_url":"https://github.com/zodb/relstorage/issues/170","id":211804075,"number":170,"title":"Why does relstorage use separate read and write connections.","user":{"login":"jimfulton","id":772727,"avatar_url":"https://avatars0.githubusercontent.com/u/772727?v=3","gravatar_id":"","url":"https://api.github.com/users/jimfulton","html_url":"https://github.com/jimfulton","followers_url":"https://api.github.com/users/jimfulton/followers","following_url":"https://api.github.com/users/jimfulton/following{/other_user}","gists_url":"https://api.github.com/users/jimfulton/gists{/gist_id}","starred_url":"https://api.github.com/users/jimfulton/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jimfulton/subscriptions","organizations_url":"https://api.github.com/users/jimfulton/orgs","repos_url":"https://api.github.com/users/jimfulton/repos","events_url":"https://api.github.com/users/jimfulton/events{/privacy}","received_events_url":"https://api.github.com/users/jimfulton/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":8,"created_at":"2017-03-03T21:15:44Z","updated_at":"2017-03-03T23:01:06Z","closed_at":null,"body":"This is related to #125.\r\n\r\nA basic idea of RelStorage is that we rely on the underlying DB's MVCC, except that we don't.\r\n\r\nWe sort of do for reads, but we still check for conflicts ourselves. And manage locks. :(\r\n\r\nIf we just used a single connection we could do away with locks, couldn't we? At least in a history-free-like configuration?\r\n\r\nI imagine this was tried and rejected for good reason. It would be interesting to know what those reasons were, perhaps in the wiki here or in a checked in file.  \r\n\r\nOTOH, I could imagine that the traditional ZODB history-preserving model got in the way.  Maybe there's a simpler model for applications that don't need time travel."},"comment":{"url":"https://api.github.com/repos/zodb/relstorage/issues/comments/284094467","html_url":"https://github.com/zodb/relstorage/issues/170#issuecomment-284094467","issue_url":"https://api.github.com/repos/zodb/relstorage/issues/170","id":284094467,"user":{"login":"jamadden","id":1256082,"avatar_url":"https://avatars0.githubusercontent.com/u/1256082?v=3","gravatar_id":"","url":"https://api.github.com/users/jamadden","html_url":"https://github.com/jamadden","followers_url":"https://api.github.com/users/jamadden/followers","following_url":"https://api.github.com/users/jamadden/following{/other_user}","gists_url":"https://api.github.com/users/jamadden/gists{/gist_id}","starred_url":"https://api.github.com/users/jamadden/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jamadden/subscriptions","organizations_url":"https://api.github.com/users/jamadden/orgs","repos_url":"https://api.github.com/users/jamadden/repos","events_url":"https://api.github.com/users/jamadden/events{/privacy}","received_events_url":"https://api.github.com/users/jamadden/received_events","type":"User","site_admin":false},"created_at":"2017-03-03T23:01:06Z","updated_at":"2017-03-03T23:01:06Z","body":"> Newt might not.  After all, if you don't use catalogs, you eliminate the\r\n> biggest source of conflicts. \r\n\r\nBTrees are also the basis of folders and other such containers. Even without catalogs those still conflict and they're commonly resolvable. \r\n\r\nzope.minmax objects also conflict and resolve often in some applications.\r\n\r\n> And if by using a lighter implementation, you'd be able to go much faster, \r\n\r\nIt's not obvious to me that there is a lighter implementation that would be \"much faster\", even if we're just talking about PostgreSQL. The time should be dominated by the IO, and that would be basically the same. At most you eliminate the one query that's used to detect conflicts (which would return nothing, because we're optimizing for the case that there are no conflicts) and probably the query that's used to lock tables...but those didn't ever show up in my profiling as hot spots.\r\n"}}
{"actor":{"display_login":"jamadden"}}