On Sunday 23 November 2003 5:53 pm, Tom Schindl wrote:
>
> Well it depends. I completely agree with you when the object created
> only holds a dataset e.g. table-row of the database (which is the
> situation discussed in this thread). In case you are calculating things
> upon this data it will of course make sense to cache this data. It also
> makes sense if your SQL-Statement is very complex and its costs on the
> RDBMS-side are very high.

>
> For my last project I had to shade an old and not well design
> Informix-database  behind a ***hopefully*** better designed OO-API,
> which needs nearly realtime support for television-inserts,
> online-sports-tickers, ... . In such a situation it made sense to cache
> data using Cache::Cache and sharing those data between mulitple
> processes.

We had a pretty similar sort of problem with some VERY complex queries. The 
answer I've found that seems to work best in those cases is to design a query 
which constructs an intermediate table or two and invoke it as a stored 
procedure only when necessary. Of course that may not help you if you have 
complex update queries.

>
> > Also remember that ANY cache will have to serialize all accesses to each
> > object, which if your application hits a lot of objects fairly often will
> > most likely bottleneck you at the cache with possibly serious total
> > system
>
> This is true if you have mulitple concurrent write accesses, when you
> have one writer/creator and multiple readers that's not much a problem.

Depends on the amount of writing going on, but in general thats true. 

Maybe it is partly a matter of the OS and hardware etc I was using on the 
particular project where we got heavily into looking at object caches in 
perl, but I never found one with performance that justified it. I'd be the 
last guy to say there are no such situations, they are just less common than 
people might think. 

>
-- 
Tod Harter
Giant Electronic Brain
http://www.giantelectronicbrain.com


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to