You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Alexandre Borgoltz <al...@smartjog.com> on 2005/02/15 10:12:29 UTC
[cache] Caching JDBC access
Hey all,
Simple question :
There are a few tables in my model that I know won't change during long
periods. For exemple, the list of continents won't change a lot :)
I would like to cache them in a very "strong" way, which means returning
always the same objects, WITHOUT EVEN PERFORMING ANY JDBC ACCESS.
Which part of OJB should I customize to achieve this? I guess it's not
on the ObjectCache level, because object caching occurs after the
JdbcAccess has been performed.
Is it JdbcAccess then? Something like
public ResultSetAndStatement executeQuery(Query arg0, ClassDescriptor arg1)
would look really good if if didn't return a ResultSetAndStatement,
which I guess can be used only once.
So what?
In the end, it "simply" means applying cache directly at the query
level. Don't re-execute the query (jdbc+bean population) if it has
already been performed (and is configured as cacheable...).
Thank you in advance for your help!
--
Alexandre BORGOLTZ
Head of Technology
SmartJog SA
Phone: +33 (0)1 4996 6324
Fax: +33 (0)1 4996 6405
Mobile: +33 (0)6 8882 1417
alexandre.borgoltz@smartjog.com
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: [cache] Caching JDBC access - first idea
Posted by Armin Waibel <ar...@apache.org>.
Hi Alexandre,
I would recommend to do this "strong caching" outside of OJB in a
separate class (client- or server-side). If you don't want to cache the
whole objects, e.g. all continent object, you could cache a list of
Identity objects (each persistent object has an unique identity object
in OJB, see PersistenceBroker.serviceIdentity) and lookup these objects
via PB.getObjectByIdentity, this call does first lookup the cache.
Alexandre Borgoltz wrote:
> Would it be a good idea to override
> public ResultSetAndStatement executeQuery(Query arg0, ClassDescriptor arg1)
> in JdbcAccessImpl, and cache the resultset directly?
> I could cache an instance of a "fake" resultset implementation,
> populated with the data from the "real" resultset, the first time the
> jdbc access is performed. And then always return a ResultSetAndStatement
> build upon this cached resultset.
>
If you always perform queries like "select all Continent" it will work,
but when the query look like "select all Continent where
population<1000000" and the next query is "select all Continent where
population<1000001", ...?
regards,
Armin
> What do you think? Is there a better way to go? Are there drawbacks I
> don't see?
>
> Thank you!
>
> *--
> Alexandre BORGOLTZ
> Head of Technology
>
> SmartJog SA
> Phone: +33 (0)1 4996 6324
> Fax: +33 (0)1 4996 6405
> Mobile: +33 (0)6 8882 1417
> alexandre.borgoltz@smartjog.com*
>
>
> Alexandre Borgoltz wrote:
>
>> Hey all,
>>
>> Simple question :
>> There are a few tables in my model that I know won't change during
>> long periods. For exemple, the list of continents won't change a lot :)
>> I would like to cache them in a very "strong" way, which means
>> returning always the same objects, WITHOUT EVEN PERFORMING ANY JDBC
>> ACCESS.
>> Which part of OJB should I customize to achieve this? I guess it's not
>> on the ObjectCache level, because object caching occurs after the
>> JdbcAccess has been performed.
>> Is it JdbcAccess then? Something like
>> public ResultSetAndStatement executeQuery(Query arg0, ClassDescriptor
>> arg1)
>> would look really good if if didn't return a ResultSetAndStatement,
>> which I guess can be used only once.
>> So what?
>>
>> In the end, it "simply" means applying cache directly at the query
>> level. Don't re-execute the query (jdbc+bean population) if it has
>> already been performed (and is configured as cacheable...).
>>
>> Thank you in advance for your help!
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: [cache] Caching JDBC access - first idea
Posted by Alexandre Borgoltz <al...@smartjog.com>.
Would it be a good idea to override
public ResultSetAndStatement executeQuery(Query arg0, ClassDescriptor arg1)
in JdbcAccessImpl, and cache the resultset directly?
I could cache an instance of a "fake" resultset implementation,
populated with the data from the "real" resultset, the first time the
jdbc access is performed. And then always return a ResultSetAndStatement
build upon this cached resultset.
What do you think? Is there a better way to go? Are there drawbacks I
don't see?
Thank you!
*--
Alexandre BORGOLTZ
Head of Technology
SmartJog SA
Phone: +33 (0)1 4996 6324
Fax: +33 (0)1 4996 6405
Mobile: +33 (0)6 8882 1417
alexandre.borgoltz@smartjog.com*
Alexandre Borgoltz wrote:
> Hey all,
>
> Simple question :
> There are a few tables in my model that I know won't change during
> long periods. For exemple, the list of continents won't change a lot :)
> I would like to cache them in a very "strong" way, which means
> returning always the same objects, WITHOUT EVEN PERFORMING ANY JDBC
> ACCESS.
> Which part of OJB should I customize to achieve this? I guess it's not
> on the ObjectCache level, because object caching occurs after the
> JdbcAccess has been performed.
> Is it JdbcAccess then? Something like
> public ResultSetAndStatement executeQuery(Query arg0, ClassDescriptor
> arg1)
> would look really good if if didn't return a ResultSetAndStatement,
> which I guess can be used only once.
> So what?
>
> In the end, it "simply" means applying cache directly at the query
> level. Don't re-execute the query (jdbc+bean population) if it has
> already been performed (and is configured as cacheable...).
>
> Thank you in advance for your help!
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org