You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by dragos moraru <dm...@qcns.co.ro> on 2005/06/28 11:47:11 UTC
cache behaviour
HI!
I have a SQL select to return only one resutl each time, something like: Select * from product where id=#value#
and i want to cache the results. I don't know if the cache-model configuration form ibatis will store every object the query returns or it will replace each time the last object with the new one returned by the select.
Thanks
Re: cache behaviour
Posted by Brandon Goodin <br...@gmail.com>.
The insert would definitely update the cache in that scenario.
Brandon
On 6/29/05, Daniel Henrique Ferreira e Silva <dh...@gmail.com> wrote:
> Hi all,
>
> I may be saying something really stupid, so, please, be cool with me! ;-)
>
> Based on what Brandon stated i have one question:
>
> How would that work for inserts? When you update or delete an object,
> its identity is kept. But insert is supposed to be used for 'new'
> objects, so i guess it should flush the whole cache anyway.
>
> Thoughts?
>
>
> Cheers,
> Daniel Silva.
>
>
>
> On 6/28/05, Brandon Goodin <br...@gmail.com> wrote:
> > I was kinda discussing this with larry last night. Maybe we could have
> > a typed cache that allows identity to be defined based on object
> > properties. So, only a certain type of object could be placed into
> > that cache and anything that is placed into the cache would need to
> > conform to the particular type. Perhaps a list could be decomposed to
> > examine it's contents.
> >
> > For example:
> >
> > <cacheModel type="IDENTITY" id="myIdCache">
> > <property name="type" value="myPersonObject"
> > <property name="identity-properties" value="firstName,lastName">
> > <flushOnExecute id="insert"/>
> > <flushOnExecute id="update"/>
> > <flushOnExecute id="delete"/>
> > </cacheModel>
> >
> > - the type property would specify the type of object that cache would hold
> >
> > - the identity-properties would be the combination of property values
> > that gave the object it's unique identity (getters/setters).
> >
> > - when the flushOnExecute happens the parameter class must also be of
> > the same type as those stored in the cache and it could selectively
> > update/remove cache items based on the criteria.
> >
> > I know this is a REALLY rough idea. But, if it fuels other ideas that
> > would be great.
> >
> > Brandon
> >
> > On 6/28/05, Clinton Begin <cl...@gmail.com> wrote:
> > > Might be worthwhile to start a wiki whiteboard page to discuss how this
> > > could be done.
> > >
> > > Without object identity, it would be quite hard. We could perhaps base it
> > > on .equals()/.hashCode() (hashcode not for uniqueness, but for performance).
> > >
> > >
> > > Other thoughts?
> > >
> > > Cheers,
> > > Clinton
> > >
> > >
> > > On 6/28/05, Paul Barry <pa...@gmail.com> wrote:
> > > > No, it doesn't, as far as I know, but if you find out that it does,
> > > > let me know, because fine-grain cache invalidation is a feature that I
> > > > have been wanting ibatis to have for a long time.
> > > >
> > > > On 6/28/05, Ed Griebel < edgriebel@gmail.com> wrote:
> > > > > I've just started looking at it, but doesn't using the OSCache model
> > > > > (plugin?) provide finer-grained flushing, based on the key for the
> > > > > dependant query?
> > > > >
> > > > > Thanks,
> > > > > -ed
> > > > >
> > > > > On 6/28/05, Larry Meadors <la...@gmail.com> wrote:
> > > > > > It will cache several objects returned, depending upon the cache
> > > > > > controller specified. One thing to be aware of is that the cache is
> > > > > > not aware of object identity - which means that if you update
> > > > > > *anything* in that cache, all of the objects in the cache are flushed,
> > > > > > not just the one that was updated.
> > > > > >
> > > > > > Larry
> > > > > >
> > > > > > On 6/28/05, dragos moraru <dm...@qcns.co.ro> wrote:
> > > > > > >
> > > > > > > HI!
> > > > > > > I have a SQL select to return only one resutl each time, something
> > > like:
> > > > > > > Select * from product where id=#value#
> > > > > > >
> > > > > > > and i want to cache the results. I don't know if the cache-model
> > > > > > > configuration form ibatis will store every object the query returns
> > > or it
> > > > > > > will replace each time the last object with the new one returned by
> > > the
> > > > > > > select.
> > > > > > >
> > > > > > > Thanks
> > > > > >
> > > > >
> > > >
> > >
> > >
> >
>
Re: cache behaviour
Posted by Larry Meadors <la...@gmail.com>.
True.
That would mean that either null objects could not be cached, or
inserts would have to also update the cache.
Larry
On 6/29/05, Daniel Henrique Ferreira e Silva <dh...@gmail.com> wrote:
> Hi all,
>
> I may be saying something really stupid, so, please, be cool with me! ;-)
>
> Based on what Brandon stated i have one question:
>
> How would that work for inserts? When you update or delete an object,
> its identity is kept. But insert is supposed to be used for 'new'
> objects, so i guess it should flush the whole cache anyway.
>
> Thoughts?
>
>
> Cheers,
> Daniel Silva.
>
>
>
> On 6/28/05, Brandon Goodin <br...@gmail.com> wrote:
> > I was kinda discussing this with larry last night. Maybe we could have
> > a typed cache that allows identity to be defined based on object
> > properties. So, only a certain type of object could be placed into
> > that cache and anything that is placed into the cache would need to
> > conform to the particular type. Perhaps a list could be decomposed to
> > examine it's contents.
> >
> > For example:
> >
> > <cacheModel type="IDENTITY" id="myIdCache">
> > <property name="type" value="myPersonObject"
> > <property name="identity-properties" value="firstName,lastName">
> > <flushOnExecute id="insert"/>
> > <flushOnExecute id="update"/>
> > <flushOnExecute id="delete"/>
> > </cacheModel>
> >
> > - the type property would specify the type of object that cache would hold
> >
> > - the identity-properties would be the combination of property values
> > that gave the object it's unique identity (getters/setters).
> >
> > - when the flushOnExecute happens the parameter class must also be of
> > the same type as those stored in the cache and it could selectively
> > update/remove cache items based on the criteria.
> >
> > I know this is a REALLY rough idea. But, if it fuels other ideas that
> > would be great.
> >
> > Brandon
> >
> > On 6/28/05, Clinton Begin <cl...@gmail.com> wrote:
> > > Might be worthwhile to start a wiki whiteboard page to discuss how this
> > > could be done.
> > >
> > > Without object identity, it would be quite hard. We could perhaps base it
> > > on .equals()/.hashCode() (hashcode not for uniqueness, but for performance).
> > >
> > >
> > > Other thoughts?
> > >
> > > Cheers,
> > > Clinton
> > >
> > >
> > > On 6/28/05, Paul Barry <pa...@gmail.com> wrote:
> > > > No, it doesn't, as far as I know, but if you find out that it does,
> > > > let me know, because fine-grain cache invalidation is a feature that I
> > > > have been wanting ibatis to have for a long time.
> > > >
> > > > On 6/28/05, Ed Griebel < edgriebel@gmail.com> wrote:
> > > > > I've just started looking at it, but doesn't using the OSCache model
> > > > > (plugin?) provide finer-grained flushing, based on the key for the
> > > > > dependant query?
> > > > >
> > > > > Thanks,
> > > > > -ed
> > > > >
> > > > > On 6/28/05, Larry Meadors <la...@gmail.com> wrote:
> > > > > > It will cache several objects returned, depending upon the cache
> > > > > > controller specified. One thing to be aware of is that the cache is
> > > > > > not aware of object identity - which means that if you update
> > > > > > *anything* in that cache, all of the objects in the cache are flushed,
> > > > > > not just the one that was updated.
> > > > > >
> > > > > > Larry
> > > > > >
> > > > > > On 6/28/05, dragos moraru <dm...@qcns.co.ro> wrote:
> > > > > > >
> > > > > > > HI!
> > > > > > > I have a SQL select to return only one resutl each time, something
> > > like:
> > > > > > > Select * from product where id=#value#
> > > > > > >
> > > > > > > and i want to cache the results. I don't know if the cache-model
> > > > > > > configuration form ibatis will store every object the query returns
> > > or it
> > > > > > > will replace each time the last object with the new one returned by
> > > the
> > > > > > > select.
> > > > > > >
> > > > > > > Thanks
> > > > > >
> > > > >
> > > >
> > >
> > >
> >
>
Re: cache behaviour
Posted by Daniel Henrique Ferreira e Silva <dh...@gmail.com>.
Hi all,
I may be saying something really stupid, so, please, be cool with me! ;-)
Based on what Brandon stated i have one question:
How would that work for inserts? When you update or delete an object,
its identity is kept. But insert is supposed to be used for 'new'
objects, so i guess it should flush the whole cache anyway.
Thoughts?
Cheers,
Daniel Silva.
On 6/28/05, Brandon Goodin <br...@gmail.com> wrote:
> I was kinda discussing this with larry last night. Maybe we could have
> a typed cache that allows identity to be defined based on object
> properties. So, only a certain type of object could be placed into
> that cache and anything that is placed into the cache would need to
> conform to the particular type. Perhaps a list could be decomposed to
> examine it's contents.
>
> For example:
>
> <cacheModel type="IDENTITY" id="myIdCache">
> <property name="type" value="myPersonObject"
> <property name="identity-properties" value="firstName,lastName">
> <flushOnExecute id="insert"/>
> <flushOnExecute id="update"/>
> <flushOnExecute id="delete"/>
> </cacheModel>
>
> - the type property would specify the type of object that cache would hold
>
> - the identity-properties would be the combination of property values
> that gave the object it's unique identity (getters/setters).
>
> - when the flushOnExecute happens the parameter class must also be of
> the same type as those stored in the cache and it could selectively
> update/remove cache items based on the criteria.
>
> I know this is a REALLY rough idea. But, if it fuels other ideas that
> would be great.
>
> Brandon
>
> On 6/28/05, Clinton Begin <cl...@gmail.com> wrote:
> > Might be worthwhile to start a wiki whiteboard page to discuss how this
> > could be done.
> >
> > Without object identity, it would be quite hard. We could perhaps base it
> > on .equals()/.hashCode() (hashcode not for uniqueness, but for performance).
> >
> >
> > Other thoughts?
> >
> > Cheers,
> > Clinton
> >
> >
> > On 6/28/05, Paul Barry <pa...@gmail.com> wrote:
> > > No, it doesn't, as far as I know, but if you find out that it does,
> > > let me know, because fine-grain cache invalidation is a feature that I
> > > have been wanting ibatis to have for a long time.
> > >
> > > On 6/28/05, Ed Griebel < edgriebel@gmail.com> wrote:
> > > > I've just started looking at it, but doesn't using the OSCache model
> > > > (plugin?) provide finer-grained flushing, based on the key for the
> > > > dependant query?
> > > >
> > > > Thanks,
> > > > -ed
> > > >
> > > > On 6/28/05, Larry Meadors <la...@gmail.com> wrote:
> > > > > It will cache several objects returned, depending upon the cache
> > > > > controller specified. One thing to be aware of is that the cache is
> > > > > not aware of object identity - which means that if you update
> > > > > *anything* in that cache, all of the objects in the cache are flushed,
> > > > > not just the one that was updated.
> > > > >
> > > > > Larry
> > > > >
> > > > > On 6/28/05, dragos moraru <dm...@qcns.co.ro> wrote:
> > > > > >
> > > > > > HI!
> > > > > > I have a SQL select to return only one resutl each time, something
> > like:
> > > > > > Select * from product where id=#value#
> > > > > >
> > > > > > and i want to cache the results. I don't know if the cache-model
> > > > > > configuration form ibatis will store every object the query returns
> > or it
> > > > > > will replace each time the last object with the new one returned by
> > the
> > > > > > select.
> > > > > >
> > > > > > Thanks
> > > > >
> > > >
> > >
> >
> >
>
Re: cache behaviour
Posted by Brandon Goodin <br...@gmail.com>.
I understand what you are saying. But, it may not be desireable to
express equality the same across your whole application or across all
caches. A hashcode allows you to define only one way for that objects
equality to be checked. I've never been a fan of messing around with
hashcodes and equals because you may not want that equality to be
expressed the same in every instance. But, i am not excluding the use
of hashcode either. I would just prefer to have a means of testing
equality in a broader way.
Brandon
On 6/29/05, Paul Barry <pa...@gmail.com> wrote:
> Why the need for the identity-properties? There can only be one
> paramter, right? So if the parameter is a primative, testing for
> equality is easy. If it is an object, you have to make sure the
> object implements hashCode/equals. I think that is a reasonable
> requirement, hibernate requires that. Then, if the parameter is a
> list or map, the equals methods should also work, assuming each
> element in the list or map implements equals correctly.
>
> On 6/28/05, Brandon Goodin <br...@gmail.com> wrote:
> > I was kinda discussing this with larry last night. Maybe we could have
> > a typed cache that allows identity to be defined based on object
> > properties. So, only a certain type of object could be placed into
> > that cache and anything that is placed into the cache would need to
> > conform to the particular type. Perhaps a list could be decomposed to
> > examine it's contents.
> >
> > For example:
> >
> > <cacheModel type="IDENTITY" id="myIdCache">
> > <property name="type" value="myPersonObject"
> > <property name="identity-properties" value="firstName,lastName">
> > <flushOnExecute id="insert"/>
> > <flushOnExecute id="update"/>
> > <flushOnExecute id="delete"/>
> > </cacheModel>
> >
> > - the type property would specify the type of object that cache would hold
> >
> > - the identity-properties would be the combination of property values
> > that gave the object it's unique identity (getters/setters).
> >
> > - when the flushOnExecute happens the parameter class must also be of
> > the same type as those stored in the cache and it could selectively
> > update/remove cache items based on the criteria.
> >
> > I know this is a REALLY rough idea. But, if it fuels other ideas that
> > would be great.
> >
> > Brandon
> >
> > On 6/28/05, Clinton Begin <cl...@gmail.com> wrote:
> > > Might be worthwhile to start a wiki whiteboard page to discuss how this
> > > could be done.
> > >
> > > Without object identity, it would be quite hard. We could perhaps base it
> > > on .equals()/.hashCode() (hashcode not for uniqueness, but for performance).
> > >
> > >
> > > Other thoughts?
> > >
> > > Cheers,
> > > Clinton
> > >
> > >
> > > On 6/28/05, Paul Barry <pa...@gmail.com> wrote:
> > > > No, it doesn't, as far as I know, but if you find out that it does,
> > > > let me know, because fine-grain cache invalidation is a feature that I
> > > > have been wanting ibatis to have for a long time.
> > > >
> > > > On 6/28/05, Ed Griebel < edgriebel@gmail.com> wrote:
> > > > > I've just started looking at it, but doesn't using the OSCache model
> > > > > (plugin?) provide finer-grained flushing, based on the key for the
> > > > > dependant query?
> > > > >
> > > > > Thanks,
> > > > > -ed
> > > > >
> > > > > On 6/28/05, Larry Meadors <la...@gmail.com> wrote:
> > > > > > It will cache several objects returned, depending upon the cache
> > > > > > controller specified. One thing to be aware of is that the cache is
> > > > > > not aware of object identity - which means that if you update
> > > > > > *anything* in that cache, all of the objects in the cache are flushed,
> > > > > > not just the one that was updated.
> > > > > >
> > > > > > Larry
> > > > > >
> > > > > > On 6/28/05, dragos moraru <dm...@qcns.co.ro> wrote:
> > > > > > >
> > > > > > > HI!
> > > > > > > I have a SQL select to return only one resutl each time, something
> > > like:
> > > > > > > Select * from product where id=#value#
> > > > > > >
> > > > > > > and i want to cache the results. I don't know if the cache-model
> > > > > > > configuration form ibatis will store every object the query returns
> > > or it
> > > > > > > will replace each time the last object with the new one returned by
> > > the
> > > > > > > select.
> > > > > > >
> > > > > > > Thanks
> > > > > >
> > > > >
> > > >
> > >
> > >
> >
>
Re: cache behaviour
Posted by Paul Barry <pa...@gmail.com>.
Why the need for the identity-properties? There can only be one
paramter, right? So if the parameter is a primative, testing for
equality is easy. If it is an object, you have to make sure the
object implements hashCode/equals. I think that is a reasonable
requirement, hibernate requires that. Then, if the parameter is a
list or map, the equals methods should also work, assuming each
element in the list or map implements equals correctly.
On 6/28/05, Brandon Goodin <br...@gmail.com> wrote:
> I was kinda discussing this with larry last night. Maybe we could have
> a typed cache that allows identity to be defined based on object
> properties. So, only a certain type of object could be placed into
> that cache and anything that is placed into the cache would need to
> conform to the particular type. Perhaps a list could be decomposed to
> examine it's contents.
>
> For example:
>
> <cacheModel type="IDENTITY" id="myIdCache">
> <property name="type" value="myPersonObject"
> <property name="identity-properties" value="firstName,lastName">
> <flushOnExecute id="insert"/>
> <flushOnExecute id="update"/>
> <flushOnExecute id="delete"/>
> </cacheModel>
>
> - the type property would specify the type of object that cache would hold
>
> - the identity-properties would be the combination of property values
> that gave the object it's unique identity (getters/setters).
>
> - when the flushOnExecute happens the parameter class must also be of
> the same type as those stored in the cache and it could selectively
> update/remove cache items based on the criteria.
>
> I know this is a REALLY rough idea. But, if it fuels other ideas that
> would be great.
>
> Brandon
>
> On 6/28/05, Clinton Begin <cl...@gmail.com> wrote:
> > Might be worthwhile to start a wiki whiteboard page to discuss how this
> > could be done.
> >
> > Without object identity, it would be quite hard. We could perhaps base it
> > on .equals()/.hashCode() (hashcode not for uniqueness, but for performance).
> >
> >
> > Other thoughts?
> >
> > Cheers,
> > Clinton
> >
> >
> > On 6/28/05, Paul Barry <pa...@gmail.com> wrote:
> > > No, it doesn't, as far as I know, but if you find out that it does,
> > > let me know, because fine-grain cache invalidation is a feature that I
> > > have been wanting ibatis to have for a long time.
> > >
> > > On 6/28/05, Ed Griebel < edgriebel@gmail.com> wrote:
> > > > I've just started looking at it, but doesn't using the OSCache model
> > > > (plugin?) provide finer-grained flushing, based on the key for the
> > > > dependant query?
> > > >
> > > > Thanks,
> > > > -ed
> > > >
> > > > On 6/28/05, Larry Meadors <la...@gmail.com> wrote:
> > > > > It will cache several objects returned, depending upon the cache
> > > > > controller specified. One thing to be aware of is that the cache is
> > > > > not aware of object identity - which means that if you update
> > > > > *anything* in that cache, all of the objects in the cache are flushed,
> > > > > not just the one that was updated.
> > > > >
> > > > > Larry
> > > > >
> > > > > On 6/28/05, dragos moraru <dm...@qcns.co.ro> wrote:
> > > > > >
> > > > > > HI!
> > > > > > I have a SQL select to return only one resutl each time, something
> > like:
> > > > > > Select * from product where id=#value#
> > > > > >
> > > > > > and i want to cache the results. I don't know if the cache-model
> > > > > > configuration form ibatis will store every object the query returns
> > or it
> > > > > > will replace each time the last object with the new one returned by
> > the
> > > > > > select.
> > > > > >
> > > > > > Thanks
> > > > >
> > > >
> > >
> >
> >
>
Re: cache behaviour
Posted by Brandon Goodin <br...@gmail.com>.
I was kinda discussing this with larry last night. Maybe we could have
a typed cache that allows identity to be defined based on object
properties. So, only a certain type of object could be placed into
that cache and anything that is placed into the cache would need to
conform to the particular type. Perhaps a list could be decomposed to
examine it's contents.
For example:
<cacheModel type="IDENTITY" id="myIdCache">
<property name="type" value="myPersonObject"
<property name="identity-properties" value="firstName,lastName">
<flushOnExecute id="insert"/>
<flushOnExecute id="update"/>
<flushOnExecute id="delete"/>
</cacheModel>
- the type property would specify the type of object that cache would hold
- the identity-properties would be the combination of property values
that gave the object it's unique identity (getters/setters).
- when the flushOnExecute happens the parameter class must also be of
the same type as those stored in the cache and it could selectively
update/remove cache items based on the criteria.
I know this is a REALLY rough idea. But, if it fuels other ideas that
would be great.
Brandon
On 6/28/05, Clinton Begin <cl...@gmail.com> wrote:
> Might be worthwhile to start a wiki whiteboard page to discuss how this
> could be done.
>
> Without object identity, it would be quite hard. We could perhaps base it
> on .equals()/.hashCode() (hashcode not for uniqueness, but for performance).
>
>
> Other thoughts?
>
> Cheers,
> Clinton
>
>
> On 6/28/05, Paul Barry <pa...@gmail.com> wrote:
> > No, it doesn't, as far as I know, but if you find out that it does,
> > let me know, because fine-grain cache invalidation is a feature that I
> > have been wanting ibatis to have for a long time.
> >
> > On 6/28/05, Ed Griebel < edgriebel@gmail.com> wrote:
> > > I've just started looking at it, but doesn't using the OSCache model
> > > (plugin?) provide finer-grained flushing, based on the key for the
> > > dependant query?
> > >
> > > Thanks,
> > > -ed
> > >
> > > On 6/28/05, Larry Meadors <la...@gmail.com> wrote:
> > > > It will cache several objects returned, depending upon the cache
> > > > controller specified. One thing to be aware of is that the cache is
> > > > not aware of object identity - which means that if you update
> > > > *anything* in that cache, all of the objects in the cache are flushed,
> > > > not just the one that was updated.
> > > >
> > > > Larry
> > > >
> > > > On 6/28/05, dragos moraru <dm...@qcns.co.ro> wrote:
> > > > >
> > > > > HI!
> > > > > I have a SQL select to return only one resutl each time, something
> like:
> > > > > Select * from product where id=#value#
> > > > >
> > > > > and i want to cache the results. I don't know if the cache-model
> > > > > configuration form ibatis will store every object the query returns
> or it
> > > > > will replace each time the last object with the new one returned by
> the
> > > > > select.
> > > > >
> > > > > Thanks
> > > >
> > >
> >
>
>
Re: cache behaviour
Posted by Clinton Begin <cl...@gmail.com>.
Might be worthwhile to start a wiki whiteboard page to discuss how this
could be done.
Without object identity, it would be quite hard. We could perhaps base it on
.equals()/.hashCode() (hashcode not for uniqueness, but for performance).
Other thoughts?
Cheers,
Clinton
On 6/28/05, Paul Barry <pa...@gmail.com> wrote:
>
> No, it doesn't, as far as I know, but if you find out that it does,
> let me know, because fine-grain cache invalidation is a feature that I
> have been wanting ibatis to have for a long time.
>
> On 6/28/05, Ed Griebel <ed...@gmail.com> wrote:
> > I've just started looking at it, but doesn't using the OSCache model
> > (plugin?) provide finer-grained flushing, based on the key for the
> > dependant query?
> >
> > Thanks,
> > -ed
> >
> > On 6/28/05, Larry Meadors <la...@gmail.com> wrote:
> > > It will cache several objects returned, depending upon the cache
> > > controller specified. One thing to be aware of is that the cache is
> > > not aware of object identity - which means that if you update
> > > *anything* in that cache, all of the objects in the cache are flushed,
> > > not just the one that was updated.
> > >
> > > Larry
> > >
> > > On 6/28/05, dragos moraru <dm...@qcns.co.ro> wrote:
> > > >
> > > > HI!
> > > > I have a SQL select to return only one resutl each time, something
> like:
> > > > Select * from product where id=#value#
> > > >
> > > > and i want to cache the results. I don't know if the cache-model
> > > > configuration form ibatis will store every object the query returns
> or it
> > > > will replace each time the last object with the new one returned by
> the
> > > > select.
> > > >
> > > > Thanks
> > >
> >
>
Re: cache behaviour
Posted by Paul Barry <pa...@gmail.com>.
No, it doesn't, as far as I know, but if you find out that it does,
let me know, because fine-grain cache invalidation is a feature that I
have been wanting ibatis to have for a long time.
On 6/28/05, Ed Griebel <ed...@gmail.com> wrote:
> I've just started looking at it, but doesn't using the OSCache model
> (plugin?) provide finer-grained flushing, based on the key for the
> dependant query?
>
> Thanks,
> -ed
>
> On 6/28/05, Larry Meadors <la...@gmail.com> wrote:
> > It will cache several objects returned, depending upon the cache
> > controller specified. One thing to be aware of is that the cache is
> > not aware of object identity - which means that if you update
> > *anything* in that cache, all of the objects in the cache are flushed,
> > not just the one that was updated.
> >
> > Larry
> >
> > On 6/28/05, dragos moraru <dm...@qcns.co.ro> wrote:
> > >
> > > HI!
> > > I have a SQL select to return only one resutl each time, something like:
> > > Select * from product where id=#value#
> > >
> > > and i want to cache the results. I don't know if the cache-model
> > > configuration form ibatis will store every object the query returns or it
> > > will replace each time the last object with the new one returned by the
> > > select.
> > >
> > > Thanks
> >
>
Re: cache behaviour
Posted by Ed Griebel <ed...@gmail.com>.
I've just started looking at it, but doesn't using the OSCache model
(plugin?) provide finer-grained flushing, based on the key for the
dependant query?
Thanks,
-ed
On 6/28/05, Larry Meadors <la...@gmail.com> wrote:
> It will cache several objects returned, depending upon the cache
> controller specified. One thing to be aware of is that the cache is
> not aware of object identity - which means that if you update
> *anything* in that cache, all of the objects in the cache are flushed,
> not just the one that was updated.
>
> Larry
>
> On 6/28/05, dragos moraru <dm...@qcns.co.ro> wrote:
> >
> > HI!
> > I have a SQL select to return only one resutl each time, something like:
> > Select * from product where id=#value#
> >
> > and i want to cache the results. I don't know if the cache-model
> > configuration form ibatis will store every object the query returns or it
> > will replace each time the last object with the new one returned by the
> > select.
> >
> > Thanks
>
Re: cache behaviour
Posted by Larry Meadors <la...@gmail.com>.
It will cache several objects returned, depending upon the cache
controller specified. One thing to be aware of is that the cache is
not aware of object identity - which means that if you update
*anything* in that cache, all of the objects in the cache are flushed,
not just the one that was updated.
Larry
On 6/28/05, dragos moraru <dm...@qcns.co.ro> wrote:
>
> HI!
> I have a SQL select to return only one resutl each time, something like:
> Select * from product where id=#value#
>
> and i want to cache the results. I don't know if the cache-model
> configuration form ibatis will store every object the query returns or it
> will replace each time the last object with the new one returned by the
> select.
>
> Thanks