Re: [hibernate-dev] WildFly, JtaPlatform and Hibernate OGM
On 09/01/2014 07:20 AM, Gunnar Morling wrote: > Hi, > > Running an OGM integration test on WildFly, I noticed that we work with > JBossStandAloneJtaPlatform. Shouldn't it rather be > JBossAppServerJtaPlatform in this case so we make use of the transaction > manager from the container? org.hibernate.engine.transaction.jta.platform.internal.JBossAppServerJtaPlatform sounds better. > > So I thought it might help to add jipijapa-hibernate4-3.jar to the OGM > module, as it provides HibernatePersistenceProviderAdaptor which in turn > sets the JBossAppServerJtaPlatform. This works indeed, but unfortunately > HibernatePersistenceProviderAdaptor always bootstraps Hibernate ORM by > calling ORM's EMF builder. There was a memory leak in Hibernate, see [1] [2] [3] for more details. > > What'd be the right way to solve this problem? Have a specific JipiJapa > adaptor for OGM? Or could the existing one for ORM 4.3 actually be used if > it invoked the configured PersistenceProvider (HibernateOgmPersistence in > our case) rather than directly delegating to ORM's Bootstrap class? No reason why there couldn't be a JipiJapa adaptor for OGM. One question to answer is whether there will only be one JipiJapa adapter for all versions of OGM or a different Jipi adaptor per OGM minor release (as we do for ORM currently). Currently, the JipiJapa release cycle tries to be in sync with the WildFly schedule. At the moment, Jipi is lagging behind and needs to catch up on feature development. The missing feature at the moment, is enabling 2lc clustering via Jipi callbacks, that will allow more persistence providers to cluster the 2lc (with WildFly). Currently, we only allow the very latest supported Hibernate ORM 2lc to be clustered. Scott [1] https://issues.jboss.org/browse/JIPI-13 reverted the https://issues.jboss.org/browse/JIPI-8 change due to memory leak. [2] http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000466.html [3] https://hibernate.atlassian.net/browse/HHH-8363 (ClassLoaderServiceImpl should be defined as Stoppable) [4] https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jboss/as/jpa/config/Configuration.java#L55 > > Thanks, > > --Gunnar > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Projecting an index
I'm wondering if would be conceivable to project a custom index based on the programmatic API when you are also using Annotations? Our use case is basically that we have a social "wall" where we retrieve "posts" which can reference related objects: other posts, user info, classifieds, events, groups, etc. In most cases, we'll reference these with a title, url, description and photo. Additionally, each object can have a specific property, such as an event having a startDate and an RSVP. We don't store this information directly in the post index because changes in them could affect a large number of posts and have undesired performance impacts We are avoiding to load stuff from the database because of the load each retrieval could generate and are basically loading as much as possible from the index. One alternative approach would be to use the index to load post ids and then load the posts as is from the database = large number of queries through lazy initialization. We went the pure index way. In order to load all this information each load of a list of posts requires some preloading and some iterations to first load the posts and then load related objects from their own indices. This kind of staggered approach offers some nice caching opportunities. But ideally, I would like to have a limited flattened index that contains all the related data for a post, but that does allow me to automatically update data in it if the underlying object changes. ideally, I would like to store in that index something like this object class id title url description photo [custom fields] I'm curious if something like this would be achievable with HSearch? ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
