caching advice? and metadata-driven usage

[Greg Meddles <gr...@nisc-llc.com>]

Hello,

My complements:  I've been using empire-db for about two months to build a service that provides very dynamic data access to a series of semi-static ROLAP database schemas for use with RIA data visualization.  My implementation uses empire-db classes in a way that is entirely runtime configured, as opposed to the typical compile-time usages shown in your examples (but probably not totally dissimilar to your code generator).  The largest benefit I receive from empire-db on this particular project is vendor-neutral SQL generation.  However, I've used every conceivable java persistence technology over the past dozen years (JDBC, early EJB entity beans, SolarMetric Kodo, Hibernate, Ibatis, JPA, ad infinitum) and I think empire-db strikes the perfect balance of flexibility and ease-of-use for a typical transaction processing application. Great job!  I wish empire-db would get a little more exposure with the technology bloggers, because I only found out about this great technology by accidental, yet providential, google search for something very specific.

My question:  I'd like to now improve performance by adding caching to reduce the cost of aggregation for mostly-static data.  Do you have any recommendations for using empire-db with any of the common open source java caching projects?  I'd particularly like to leverage the db itself for secondary cache (when a LRU method purges cache entries from memory).  Ideally I'd like to use a true data table as opposed to serialization of cache entries into a BLOB column.  

Sorry for the long email, but thanks in advance.
Greg

re: caching advice? and metadata-driven usage

[Rainer Döbele <do...@esteam.de>]

Dear Greg,

first I am pleased to hear that from all those components mentioned you prefer Empire-db.

Unfortunately I personally don't have any experience with caching frameworks (Maybe someone else has). 
I mostly use it for applications that involve user interaction and in these cases caching is always problematic.
But surely for mostly static OLAP data I can see the benefit.

Depending on how exactly you work with Empire-db you might want to try overriding the method readRecord(DBRecord rec, Object[] key, Connection conn) in a class derived from DBTable and put your caching code in there. However it is hard to give a good advice without knowing the exact problem.

But if you find a solution for your caching problem I would be interested to know how you have solved it.

Regards,
Rainer


Greg Meddles wrote:
> re: caching advice? and metadata-driven usage
> 
> Hello,
> 
> My complements:  I've been using empire-db for about two months to build
> a service that provides very dynamic data access to a series of semi-
> static ROLAP database schemas for use with RIA data visualization.  My
> implementation uses empire-db classes in a way that is entirely runtime
> configured, as opposed to the typical compile-time usages shown in your
> examples (but probably not totally dissimilar to your code generator).
> The largest benefit I receive from empire-db on this particular project
> is vendor-neutral SQL generation.  However, I've used every conceivable
> java persistence technology over the past dozen years (JDBC, early EJB
> entity beans, SolarMetric Kodo, Hibernate, Ibatis, JPA, ad infinitum)
> and I think empire-db strikes the perfect balance of flexibility and
> ease-of-use for a typical transaction processing application. Great job!
> I wish empire-db would get a little more exposure with the technology
> bloggers, because I only found out about this great technology by
> accidental, yet providential, google search for something very specific.
> 
> My question:  I'd like to now improve performance by adding caching to
> reduce the cost of aggregation for mostly-static data.  Do you have any
> recommendations for using empire-db with any of the common open source
> java caching projects?  I'd particularly like to leverage the db itself
> for secondary cache (when a LRU method purges cache entries from
> memory).  Ideally I'd like to use a true data table as opposed to
> serialization of cache entries into a BLOB column.
> 
> Sorry for the long email, but thanks in advance.
> Greg