<convinced> :) </convinced> but isn't there some way to map multiple results to a single object? can't an object be backed by a result set, so all results aren't in memory?
> -----Original Message----- > From: Andrus Adamchik [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, April 03, 2002 10:09 PM > To: Jakarta General List > Subject: Re: Open Source JDO Implementation?? > > > Actually this is not that simple. I don't remember how JDO > handles it, > but here is the general problem description. Within any O/R layer you > would need to maintain a balance between 2 things - fresh data and > caching for performance. Lets take a look at 2 extremes: > > > 1. Objects data is never cached. > > Every time you need to read an object, a query needs to be > issued to the > database. This is bad for 2 reasons - speed (since database > queries are > relatively slow), exessive object creation. Every time > somebody does a > fetch from a table with 10000 rows, 10000 objects will be > created. Next > second the same user hits "search again" button and gets a new 10000 > objects again. This new batch of objects is logically the > same objects, > since they represent the same database rows. But since we had > no cache, > we have to create them again, all 10000 of them. Very slow.... > > 2. Objects are always cached. > > There is an application-wide cache. Every time you need an > object with a > certain id, it is first looked up in the cache, and only if it is not > there, it is being fetched from the database. Good for > performance, but > bad for everything else. Problems with this is large memory footprint > (eventually you can suck the whole database in the cache), > stale data. > Stale data is the worst of the two. Especially when the database is > being updated externally via SQL or from other applications (which is > the case in 99% of real life scenarious). > > > > A balanced O/R layer would have some sort of combination of the two > abovementioned approaches. It would maintain the cache, > expire it when > needed (very non-trivial task in fact), and also would give user an > opportunity to explicitly bypass the cache. IMHO if this problem > (caching vs. fresh data) is solved properly, O/R way would rule the > world :-). State of the art now is pretty close via different > optimization techniques, etc. but there is still lots of > mileage to cover. > > > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > - Andrei (a.k.a. Andrus) Adamchik > Home of Cayenne - O/R Persistence Framework > http://objectstyle.org/cayenne/ > email: andrus-jk at objectstyle dot org > > > Sale, Doug wrote: > > <suspicious>how so?</suspicious> > > > > doug :) > > > >>>>Note JDO are not scalable nd only simple. > >>> > >>>I know this isn't the place to discuss this, > >>>but couldn't resist asking for the reasons > >>>supporting this assertion. > >> > >>Without caching, they lead to excessive object creation. > >> > >>-- > >>To unsubscribe, e-mail: > >><mailto:[EMAIL PROTECTED]> > >>For additional commands, e-mail: > >><mailto:[EMAIL PROTECTED]> > >> > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
