Re: Lost updates vs resumable connections/transactions
От | Greg Stark |
---|---|
Тема | Re: Lost updates vs resumable connections/transactions |
Дата | |
Msg-id | 87is73qrde.fsf@stark.xeocode.com обсуждение исходный текст |
Ответ на | Re: Lost updates vs resumable connections/transactions (Jan Wieck <JanWieck@Yahoo.com>) |
Ответы |
Re: Lost updates vs resumable connections/transactions
|
Список | pgsql-interfaces |
Jan Wieck <JanWieck@Yahoo.com> writes: > Even applications that have statefull enduser terminals (like SAP R/3 for > example) never allow an open transaction over user interaction. I'm not sure using SAP as your paragon of design excellence is a wise choice here. From what I understand SAP implemented its own locking system because the database it was based on didn't offer any locking at all. But your basic point is sound. For a web site I would definitely avoid using anything like database locks and even avoid doing anything with application locks if possible. If you really really want to expose the database session state I think he's on the right track using SQLRelay. This would let him handle reconnecting a user with her session even if she's connecting to a different Apache process. I suspect the database wouldn't really be able to suspend a database connection using any less memory than just keeping the entire backend process with its session around anyways. -- greg
В списке pgsql-interfaces по дате отправления: