---------- Forwarded Message ----------
Date: Friday 03 March 2006 06:37
From: John Muehlhausen <[EMAIL PROTECTED]>
David, I still can't get on the list. What do you think about
posting this on my behalf?
---
SQLObject currently allows objects to be cached -- that is, for
values to be read from memory instead of from the database.
I am assuming that nobody regrets this decision or thinks that it is
an inappropriate place for the functionality. That is, nobody
assumes that the underlying SQL client library should be responsible
for caching, if it is desired.
So then, what are the data access modes currently supported? (or at
least proposed to be supported)
a) more consistent read: "select ... for update" (proposed)
b) less consistent read: "select"
c) even less consistent read: from cache
There is a tension between (b) and (c): select from the database
server will provide access to recent updates from other clients,
while the cache will provide significantly better performance.
We should ask the question, "Can we have the performance of the cache
with inclusion of recent updates from other clients?"
If so, then the need for (b) diminishes and we can rely more and more
on (a) and on (c).
We (myself and David Faure) are proposing that SQLObject support
cache mechanisms that have the following properties:
- when an object is persisted to the database, a registered delegate
may distribute that object update to other client caches, either
directly or via one or more cache manager processes
- when an object is requested from the cache, a registered delegate
handles the actual lookup from a potentially user-supplied cache
mechanism, e.g., one that uses shared memory
In our particular application, we want each SQLObject update to
notify one cache manager process per server that hosts clients of the
"object database." Each cache manager populates a (single writer,
many readers) shared memory database of objects for that server.
Each SQLObject client has the option of fetching object state from
the shared memory.
Of course the API for these delegates should be carefully
considered. For example, it would probably be good if the update
notification delegate were not triggered until after committing the
transaction that touched the object(s) in question, so as not to
advertise object state that never really existed.
I would be interested in thoughts on this approach, and in particular
in arguments against it. I would hope that the latter would be
accompanied by a better suggestion for how to examine recent state of
SQLObjects in a distributed system with queries outweighing data
modifications by at least 50000 to 1.
Here is an alternative that was considered, along with why it was
rejected:
Set up MySQL (our backing store) replicas on each server that would
otherwise host a cache manager. Then SQLObject would be directed to
fetch an object either from the remote database server or from the
local server ("cache") via UNIX domain socket.
This was rejected because the query parsing and message passing
(versus dereferencing) and internal locking mechanisms of MySQL, even
with a non-transactional storage engine, are not up to the query load
we present. These objections are not foreign to SQLObject as they
form the basis for the non-distributed cache rationale.
This idea takes cues from another object database: ObjectStore has
the ability to set up MVCC caches (multi-version concurrency
control). Further, the same client can have a MVCC view and a fully
consistent view of the object(s) at the same time. So far we have
(a) and (b) above, only "cache forward," thus eliminating the need
for (c) and improving on it somewhat. ObjectStore clients can also
register to receive update notifications from the ObjectStore server,
which can be used to refresh the MVCC cache at update time rather
than at query time. This approximates the functionality that we
would like to add to SQLObject...
-John
-------------------------------------------------------
--
David Faure -- [EMAIL PROTECTED], [EMAIL PROTECTED]
KDE/KOffice developer, Qt consultancy projects
Klarälvdalens Datakonsult AB, Platform-independent software solutions
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
sqlobject-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
