hibernate-devel

[Hibernate] serialized/deserialized criteria and query cache issue

[Mario I. <ma...@op...>]

Hi!

I already posted on the user list, but I looks like due to the massive
posts it got lost.
I took many time to think about this issue, and so I'll post it to your
dev list as I'll eventually try to create a patch for it.

Hibernate version:
3.2.0 rc1

A serialized/deserialized DetachedCriteria do not work correctly with
the query cache.
The problem is the ResultTransformer in QueryKey.

In CriteraImpl the resultTransformer will be set to Criteria.ROOT_ENTITY.
This makes it down into the QueryKey.

After serialize/deserialize the instance of resultTransformer in
CriteriaImpl has changed (not that a surprise ;-) ) and thus - in the
end - the QueryKey changed.

Subsequent lookup in the query-cache will no longer work.
The query will be executed again and put int the query-cache.
The cache grows - every lookup failes.

I think every ResultTransformer used as singleton should implement some
custom deserialization code so that always the same instance will be
returned - this is one solution.

What solution do you prefer? Just in case I manage to send a patch.

Thanks!
Ciao,
Mario

Re: [Hibernate] serialized/deserialized criteria and query cache issue

[Max R. A. <max...@jb...>]

could probably just be solved with a proper equals/hashcode impl; but
custom serialization would also work but not if it influences possible  
subclasses.

> Hi!
>
> I already posted on the user list, but I looks like due to the massive
> posts it got lost.
> I took many time to think about this issue, and so I'll post it to your
> dev list as I'll eventually try to create a patch for it.
>
> Hibernate version:
> 3.2.0 rc1
>
> A serialized/deserialized DetachedCriteria do not work correctly with
> the query cache.
> The problem is the ResultTransformer in QueryKey.
>
> In CriteraImpl the resultTransformer will be set to Criteria.ROOT_ENTITY.
> This makes it down into the QueryKey.
>
> After serialize/deserialize the instance of resultTransformer in
> CriteriaImpl has changed (not that a surprise ;-) ) and thus - in the
> end - the QueryKey changed.
>
> Subsequent lookup in the query-cache will no longer work.
> The query will be executed again and put int the query-cache.
> The cache grows - every lookup failes.
>
> I think every ResultTransformer used as singleton should implement some
> custom deserialization code so that always the same instance will be
> returned - this is one solution.
>
> What solution do you prefer? Just in case I manage to send a patch.
>
> Thanks!
> Ciao,
> Mario
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job  
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> hibernate-devel mailing list
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel



-- 
--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
ma...@hi...
http://hibernate.org

JBoss Inc
max...@jb...

Re: [Hibernate] serialized/deserialized criteria and query cache issue

[Mario I. <ma...@op...>]

Max Rydahl Andersen schrieb:
> could probably just be solved with a proper equals/hashcode impl
Yes, I also thought about it, but also thought you'll consider this as a
hack ;-)
But with the "subclass" problem in mind it might be easier to solve it
that way.

What do you think about an abstract class named
StatelessResultTransformer which will implement equals hashcode by
delegating to class.hashCode() and class.equals().

Hibernates default transformer should extend from this class then. The
user can make it statefull (if required) by overriding hashCode() equals().


Ciao,
Mario

Re: [Hibernate] serialized/deserialized criteria and query cache issue

[Max R. A. <max...@jb...>]

On Fri, 05 May 2006 12:26:27 +0200, Mario Ivankovits <ma...@op...>  
wrote:

> Max Rydahl Andersen schrieb:
>> could probably just be solved with a proper equals/hashcode impl
> Yes, I also thought about it, but also thought you'll consider this as a
> hack ;-)
> But with the "subclass" problem in mind it might be easier to solve it
> that way.
>
> What do you think about an abstract class named
> StatelessResultTransformer which will implement equals hashcode by
> delegating to class.hashCode() and class.equals().

No. it should just implement a proper equals/hashcode, no need to  
introduce a new class.

-- 
--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
ma...@hi...
http://hibernate.org

JBoss Inc
max...@jb...

Re: [Hibernate] serialized/deserialized criteria and query cache issue

[Mario I. <ma...@op...>]

Hi Max!
>> What do you think about an abstract class named
>> StatelessResultTransformer which will implement equals hashcode by
>> delegating to class.hashCode() and class.equals().
>
> No. it should just implement a proper equals/hashcode, no need to
> introduce a new class.
Ok, I'll do so, though I am not happy with this.

Not implementing those methods will not make the system fail, but will
result in unnecessary database requests.
And its damn hard to figure out why this happen, not only for you (the
developers) but also for the user - if not impossible for them.
This again might result in additional user posts in your forum.

Introducing two new methods to the ResultTransformer interface would be
great, though, I know that such interface changes are bad.
For now, I'll add this to the ResultTransformer javadoc. Hopefully the
users read them.

Thanks for your assistance!
Ciao,
Mario

Re: [Hibernate] serialized/deserialized criteria and query cache issue

[Max R. A. <max...@jb...>]

On Fri, 05 May 2006 14:52:08 +0200, Mario Ivankovits <ma...@op...>  
wrote:

> Hi Max!
>>> What do you think about an abstract class named
>>> StatelessResultTransformer which will implement equals hashcode by
>>> delegating to class.hashCode() and class.equals().
>>
>> No. it should just implement a proper equals/hashcode, no need to
>> introduce a new class.
> Ok, I'll do so, though I am not happy with this.

Why not ? it should only be done on resulttransformers which are actually  
possible to reuse.

>
> Not implementing those methods will not make the system fail, but will
> result in unnecessary database requests.
> And its damn hard to figure out why this happen, not only for you (the
> developers) but also for the user - if not impossible for them.
> This again might result in additional user posts in your forum.
>
> Introducing two new methods to the ResultTransformer interface would be
> great, though, I know that such interface changes are bad.
> For now, I'll add this to the ResultTransformer javadoc. Hopefully the
> users read them.
>
> Thanks for your assistance!
> Ciao,
> Mario
>



-- 
--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
ma...@hi...
http://hibernate.org

JBoss Inc
max...@jb...

Re: [Hibernate] serialized/deserialized criteria and query cache issue

[Mario I. <ma...@op...>]

Hi Max!
>> What do you think about an abstract class named
>> StatelessResultTransformer which will implement equals hashcode by
>> delegating to class.hashCode() and class.equals().
>
> No. it should just implement a proper equals/hashcode, no need to
> introduce a new class.

Here http://opensource.atlassian.com/projects/hibernate/browse/HHH-1722
you will find the patch for this.
Its the attachement with number 1. (6kb) 05/May/06 01:43 PM.

Ciao,
Mario