Re: Mixing OO and DB
Date: Sat, 01 Mar 2008 10:20:26 -0500
Eric <eric_at_deptj.demon.co.uk> writes:
> On 2008-02-29, Patrick May <pjm_at_spe.com> wrote: >> Eric <eric_at_deptj.demon.co.uk> writes: >>> On 2008-02-29, Patrick May <pjm_at_spe.com> wrote:
>>>> frebe <frebe73_at_gmail.com> writes:
>>>>>> Typically, once a core set of objects have been instantiated,
>>>>>> access to related objects is via reference rather than
>>>>>> repeated, explicit database access.
>>>>> And obviously introducing synchronization issues...
>>>> You are assuming that the database is always the system of
>>>> record and that the system is data-centric. Those assumptions
>>>> are not always valid so your "obvious" synchronization issues do
>>>> not occur. There are more ways of building large scale
>>>> distributed systems than are dreamt of in your RDBMS.
>>> >>> So what is the system of record? >> >> For some systems I've worked on recently, it has been a highly >> distributed shared memory holding a disjoint object graph. > > With no persistence or backup? The nodes of the distributed shared memory are backed upsynchronously to other nodes. The number of backup nodes is configurable to achieve whatever level of reliability needed. Disaster recovery is supported by a similar mechanism optimized for replication over a WAN.
Persistence is performed asynchronously, both to keep the database latency out of the critical path of the transaction and to take advantage of the faster performance of batch operations.
These systems are in the financial services and telco industries; extremely low latency and high throughput are essential.
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation. pjm_at_spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)Received on Sat Mar 01 2008 - 16:20:26 CET