Andrus Adamchik <andru..bjectstyle.org> schrieb am 16.02.03 19:52:38:
> Since you are bringing up an interesting scenario for this new feature,
> could you describe the flow some more? Are the objects mostly created in
> memory and then saved? How big of a transactional scope you need? I
> mean, you don't plan to keep millions of uncommitted objects in the
> memory at once? Or do you, and you simple write them via batch one by
> one and do a commit after that?
Hi Andrus,
the most demanding problem in terms of performance are
business-processes that effect e.g. 500.000 out of 5 Mio
customers/accounts. For each customer, we have to read a
dozen objects, change a handful and create 1 or 2 new.
We did technology prototypes based on either plain jdbc
or stored procs that reach the required performance.
In the plain jdbc code, the read direction was optimzed
using select queries with " WHERE id IN (?,?,?,?,?,...)"
to batch-read the objects for a list of primary keys,
and the write direction used batch updates/inserts
via addBatch()/executeBatch() on prepared statements.
There's no significant performance-difference if the
batch-size is 100 or 1000, so think of 100 customers
(->2000 objects) as the transactional scope.
(plus some ten thousand objects master data that
should stay in memory during the process)
Obvious problem in that code is the poor separation
of the business-logic and jdbc-logic and the pitfall
of simulatounsly changing 2 copies of the same object...
So we need real O/R-Mapping with object identity, but
basically keep the underlying db-access mechanism of
batch read/write.
It's clear that the reading will always require
some explicit programming, but having a commit-
engine doing the write transparantly (and still
fast) would be cool...
with best regards,
Arndt
-- Dr. Arndt Brenschede DIAMOS AG Innovapark Am Limespark 2 65843 SulzbachTel.: +49 (0) 61 96 - 65 06 - 134 Fax: +49 (0) 61 96 - 65 06 - 100 mobile: +49 (0) 151 151 36 134 mailto:arndt.brensched..iamos.com http://www.diamos.com
This archive was generated by hypermail 2.0.0 : Mon Feb 17 2003 - 07:47:39 EST