[hibernate-dev] [ISPN-6] Switch to distribution for default entity/collection cache?
Hi, While working on documenting the Infinispan cache provider, I've been thinking on the default cache settings for each Hibernate type: - Entity/Collection: Bearing in mind the requirement to keep this cache synchronous, in the past we've gone for invalidation rather than replication because using replication could mean having to replicate a lot of data to all nodes in the cluster. For Infinispan however, I was thinking of the possibility of making sync distribution default for entities though since we are not replicating to everyone any more. One doubt I have about here is how much of an advantage would be to bring an entity from another node in the cluster if present (distribution) vs loading it from the database if not available in the local cache (invalidation). The one downside I see of distribution vs invalidation is that if an entity is not available locally and is not available in the cluster, distribution is more expensive that invalidation, since dist involves round trip in cluster and round trip to database, vs round trip to database with invalidation. However, unless eviction kicks in, this should only affect the 1st time an entity/collection is queried cos the next time, it will be distributed already and potentially in the L1 of the node that requested it if it's not one of the owners. So, I think I would make distribution default for entity/collection. Thoughts? I'd still leave an invalidated configuration in the default config file so that people can potentially swap to it if they want to. - Query: I think we should stick to same JBC2/3 default here which is local. - Timestamps: Given the chattiness of this cache, and the low size payloads, asynchronous replication still looks to me like a good default for this cache. Cheers, -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] Benchmarking 2nd level cache providers?
Totally agree with this, it would be useful also to benchmark other parts of Hibernate (not just the cache) and as general regression test. Also with Hibernate Search I have some "private tests" which are very time consuming (an hour or so) which I can't commit on trunk as unit tests; I'd like to have them somewhere, maybe regularly executed by Continuous Integration (too much work for existing Hudson?). Sanne 2009/9/1 Galder Zamarreno : > > > On 08/26/2009 05:48 PM, Mircea Markus wrote: >> Can't we write a plugin for the CacheBenchmark fwk? > > We could potentially do so but we'd be missing loads of things and we'd > have to spend a fair bit of time replicating the way Hibernate uses the > cache which is not straightforward by any means. Take in account as well > that there're several caches and cache usages involved here: entity, > collection, query and timestamps and each has a different usage pattern. > Bottom line: I don't think trying to emulate this is worth the effort. > > What is needed here is a Hibernate/JPA load/perf test environment where > the most common Hibernate usage patterns are exercised and then you swap > 2nd level cache providers. This is really what counts to the users: how > quickly I can persist N entities, how quick I can read N times an entity > that I've just persisted, how fast I can execute same query N > times...etc, these are the use cases where the cache provider must show off. > > I haven't heard anything from the HB team wrt to this, so I assume they > don't have anything like this. > >> >> On Aug 19, 2009, at 1:14 PM, Galder Zamarreno wrote: >> >>> While talking to Manik online, the topic of 2nd level cache benchmarking >>> came up and was wondering if there's a way to benchmark different 2nd >>> level cache providers in Hibernate? >>> >>> Cheers, >>> -- >>> Galder Zamarreño >>> Sr. Software Engineer >>> Infinispan, JBoss Cache >>> ___ >>> infinispan-dev mailing list >>> infinispan-...@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > ___ > infinispan-dev mailing list > infinispan-...@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] Benchmarking 2nd level cache providers?
The best bet for something like this is a separate project which pulls in the proper hibernate dependencies. Then we can talk with Juca about getting them set up on a scheduled run. However, if you want to have the configuration varied for different runs, I suggest you wait until after the discussions with the Maven developers to address the numerous specific issues we have encountered with Maven. This is exactly one of the issues "on the docket". We have issues with this "varied config" piece in the core/testsuite module. On Wed, 2009-09-02 at 06:20 -0500, Sanne Grinovero wrote: > Totally agree with this, it would be useful also to benchmark other > parts of Hibernate (not just the cache) > and as general regression test. > Also with Hibernate Search I have some "private tests" which are very > time consuming (an hour or so) which I can't > commit on trunk as unit tests; I'd like to have them somewhere, maybe > regularly executed by Continuous Integration > (too much work for existing Hudson?). > > Sanne > > 2009/9/1 Galder Zamarreno : > > > > > > On 08/26/2009 05:48 PM, Mircea Markus wrote: > >> Can't we write a plugin for the CacheBenchmark fwk? > > > > We could potentially do so but we'd be missing loads of things and we'd > > have to spend a fair bit of time replicating the way Hibernate uses the > > cache which is not straightforward by any means. Take in account as well > > that there're several caches and cache usages involved here: entity, > > collection, query and timestamps and each has a different usage pattern. > > Bottom line: I don't think trying to emulate this is worth the effort. > > > > What is needed here is a Hibernate/JPA load/perf test environment where > > the most common Hibernate usage patterns are exercised and then you swap > > 2nd level cache providers. This is really what counts to the users: how > > quickly I can persist N entities, how quick I can read N times an entity > > that I've just persisted, how fast I can execute same query N > > times...etc, these are the use cases where the cache provider must show off. > > > > I haven't heard anything from the HB team wrt to this, so I assume they > > don't have anything like this. > > > >> > >> On Aug 19, 2009, at 1:14 PM, Galder Zamarreno wrote: > >> > >>> While talking to Manik online, the topic of 2nd level cache benchmarking > >>> came up and was wondering if there's a way to benchmark different 2nd > >>> level cache providers in Hibernate? > >>> > >>> Cheers, > >>> -- > >>> Galder Zamarreño > >>> Sr. Software Engineer > >>> Infinispan, JBoss Cache > >>> ___ > >>> infinispan-dev mailing list > >>> infinispan-...@lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev > >> > > > > -- > > Galder Zamarreño > > Sr. Software Engineer > > Infinispan, JBoss Cache > > ___ > > infinispan-dev mailing list > > infinispan-...@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Steve Ebersole Hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Patch for HHH-272: Custom SQL for column gets and sets
Hi, I've submitted a patch with unit tests for HHH-272 and I'm interested in feedback. The patch allows users to specify custom SQL get and set expressions for property columns. This can be used to call SQL functions or perform some other kind of database-side conversion without giving up automatic statement generation. You use it like this: This is similar to a formula property with two differences. First, the data is backed by a real column, which gets exported with the schema. And second. the data is read-write, not read-only. The sql-get expression gets applied in predicates, order clauses, projections, etc. The patch should work for all property columns including those in components and composite-elements. I didn't try to get id, key, index, or other kinds of non-property columns to work. It is built on top of the 3.3.2.GA tag, but I can port it to trunk if necessary. I also have a patch nearly ready to expose this functionality in Hibernate Annotations in case the Core patch is accepted. If any commiters could have a look, I'd appreciate it. Thanks for your time, -Rob Hasselbaum ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Patch for HHH-272: Custom SQL for column gets and sets
On Wed, Sep 2, 2009 at 5:17 PM, Rob Hasselbaum wrote: > I've submitted a patch with unit tests for HHH-272 and I'm interested in > feedback. > Incidentally, only the "hhh-272-hbcore-patch.txt" file is relevant. The other attachments to the bug were added a long time ago by another developer, and it wasn't a complete solution. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Patch for HHH-272: Custom SQL for column gets and sets
Awesome! This is one of those things I always wanted to get implemented but it was always getting pushed down my priority list. Thanks for taking on that work. I'll definitely take a look this week. If you could work it up for trunk that would be better. New features should really not get added to maintenance releases. On Wed, 2009-09-02 at 17:17 -0400, Rob Hasselbaum wrote: > Hi, > > I've submitted a patch with unit tests for HHH-272 and I'm interested > in feedback. The patch allows users to specify custom SQL get and set > expressions for property columns. This can be used to call SQL > functions or perform some other kind of database-side conversion > without giving up automatic statement generation. You use it like > this: > > >sql-get="decrypt(credit_card_num)"/> > > > This is similar to a formula property with two differences. First, the > data is backed by a real column, which gets exported with the schema. > And second. the data is read-write, not read-only. The sql-get > expression gets applied in predicates, order clauses, projections, > etc. > > The patch should work for all property columns including those in > components and composite-elements. I didn't try to get id, key, index, > or other kinds of non-property columns to work. It is built on top of > the 3.3.2.GA tag, but I can port it to trunk if necessary. I also have > a patch nearly ready to expose this functionality in Hibernate > Annotations in case the Core patch is accepted. If any commiters could > have a look, I'd appreciate it. > > Thanks for your time, > -Rob Hasselbaum > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Steve Ebersole Hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
