Andrey, thanks. Actually I use this not well documented method to solve my problem.
And I'm proposed to at least add more info for PortableBuilder about this method. On Wed, Oct 28, 2015 at 10:19 AM, Andrey Kornev <andrewkor...@hotmail.com> wrote: > Alexey, > > PortableBuilder has an (un-documented) method hashCode(int hashCode) that > should be used to explicitly set the hashCode for the portable instance > being built. I'm not sure why this has been designed this way, but I'm > guessing that since the PortableBuilder is pretty dumb and it wouldn't know > which fields to use for hash code computation (in some cases you'd only > want to include specific portable fields rather than all fields). > > Regards > Andrey > > > Date: Wed, 28 Oct 2015 09:49:07 +0700 > > Subject: Portables hash code. > > From: akuznet...@gridgain.com > > To: dev@ignite.apache.org > > > > Igniters, > > > > I'm working on [1] "IGNITE-1753 Rework CacheJdbcPojoStore to new API." > > > > And one of subtasks is to support portable objects with JDBC store. > > > > I implemented this and during tests found a huge performance drop when I > > have PortableObject as key. > > > > After some debugging I found that all my portable objects have hashCode > = 0. > > I'm using PortableBuilder to build my portable objects. > > > > And I expected that PortableBuilder will calculate proper hash code for > me > > out of the box. > > > > I think we should at least describe in PortableBuilder javadocs that by > > default PortableBuilder will return zero hashcode? > > > > Or we should calculate hashcode in PortableBuilder.build() method? > > > > Or may be we could add boolean argument PortableBuilder.build(boolean > > generateHashCode)? > > > > Thoughts? > > > > P.S. After I added manual hashcode calculation to my CacheJdbcPojoStore > > performance drop is gone away. > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-1753 > > -- > > Alexey Kuznetsov > > GridGain Systems > > www.gridgain.com > > -- Alexey Kuznetsov GridGain Systems www.gridgain.com
