4:08 p.m.
Greetings,
I'm attempting to use Hibernate OGM with the Infinispan backend, using a
single FileCacheStore. I find the technology quite promising, and would
love to get this to run.
I'm running under Jetty, with the JbossTS.
I'm attempting something fairly simple so far:
DataGate.getTM().begin(); // returns the
JBossTSStandaloneTransactionManagerLookup().getTransactionManager(null);
EntityManager em = DataGate.createEntityManager(); // same...
try {
Document db_doc = em.find(Document.class, "12345"); //
nothing in so far.
db_doc = new Document(); // Document is a @Entity with @Id,
@GeneratorValue etc.
// set db_doc's properties
em.persist(db_doc);
} finally {
DataGate.getTM().commit();
em.close();
}
I can see some activity related to the JbossTS' XA manager (intent files
being created ...)
I can see Infinispan's FileCacheStore creating the empty cache
directories
I can see, upon commit, the transaction code decide to call things all
the way through OgmEntityPersister.execute() and
InfinispanDialect.updateTuple() (with a null original tuple cache entry,
which is okay since my database is empty).
I can see the transaction code declare the system happy and the
transaction complete, and proceed to delete the XA intent log.
What I never see, though, is any actual persistence for my data. Nor do
I see InfinispanDialect.updateTuple() somehow causing FileCacheStore's
updateBundle methods to run.
Is there something I'm missing ?
Thank you very much in advance.
-- Cyrille
PS:
<dependency>
<groupId>org.infinispan</groupId>
<artifactId>infinispan</artifactId>
<version>5.0.0.FINAL</version>
<type>pom</type>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.jboss.jbossts</groupId>
<artifactId>jbossjta</artifactId>
<version>4.15.3.Final</version>
<exclusions>
<exclusion>
<artifactId>jboss-logging-spi</artifactId>
<groupId>org.jboss.logging</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.hibernate.ogm</groupId>
<artifactId>hibernate-ogm-core</artifactId>
<version>3.0.0.Alpha2</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
4:18 p.m.
Hi Cyrille,
5.0.0.FINAL was just released last week, and unfortunately introduced
a last minute API change which broke compatibility with OGM/Alpha2.
OGM master works fine now as it was a trivial fix, and I've deployed
an updated SNAPSHOT version, please try that one!
Not sure why it looked like to boot in your case.. you should have
seen a stacktrace at startup mentioning that Infinispan couldn't be
started,
please check your logs too.
Sanne
2011/8/12 Cyrille Chépélov <cyrille(a)chepelov.org>:
Greetings,
I'm attempting to use Hibernate OGM with the Infinispan backend, using a
single FileCacheStore. I find the technology quite promising, and would
love to get this to run.
I'm running under Jetty, with the JbossTS.
I'm attempting something fairly simple so far:
DataGate.getTM().begin(); // returns the
JBossTSStandaloneTransactionManagerLookup().getTransactionManager(null);
EntityManager em = DataGate.createEntityManager(); // same...
try {
Document db_doc = em.find(Document.class, "12345"); //
nothing in so far.
db_doc = new Document(); // Document is a @Entity with @Id,
@GeneratorValue etc.
// set db_doc's properties
em.persist(db_doc);
} finally {
DataGate.getTM().commit();
em.close();
}
I can see some activity related to the JbossTS' XA manager (intent files
being created ...)
I can see Infinispan's FileCacheStore creating the empty cache
directories
I can see, upon commit, the transaction code decide to call things all
the way through OgmEntityPersister.execute() and
InfinispanDialect.updateTuple() (with a null original tuple cache entry,
which is okay since my database is empty).
I can see the transaction code declare the system happy and the
transaction complete, and proceed to delete the XA intent log.
What I never see, though, is any actual persistence for my data. Nor do
I see InfinispanDialect.updateTuple() somehow causing FileCacheStore's
updateBundle methods to run.
Is there something I'm missing ?
Thank you very much in advance.
-- Cyrille
PS:
<dependency>
<groupId>org.infinispan</groupId>
<artifactId>infinispan</artifactId>
<version>5.0.0.FINAL</version>
<type>pom</type>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.jboss.jbossts</groupId>
<artifactId>jbossjta</artifactId>
<version>4.15.3.Final</version>
<exclusions>
<exclusion>
<artifactId>jboss-logging-spi</artifactId>
<groupId>org.jboss.logging</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.hibernate.ogm</groupId>
<artifactId>hibernate-ogm-core</artifactId>
<version>3.0.0.Alpha2</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:43 p.m.
Le vendredi 12 août 2011 à 15:18 +0100, Sanne Grinovero a écrit :
Hi Cyrille,
5.0.0.FINAL was just released last week, and unfortunately introduced
a last minute API change which broke compatibility with OGM/Alpha2.
OGM master works fine now as it was a trivial fix, and I've deployed
an updated SNAPSHOT version, please try that one!
Not sure why it looked like to boot in your case.. you should have
seen a stacktrace at startup mentioning that Infinispan couldn't be
started,
please check your logs too.
Thanks Sanne,
Infinispan appears to boot. When configuring a GUI to talk to the app, I
can see both nodes talking to each other, and no log messages to the
contrary seem to happen.
Just tried with hibernate-ogm as such:
<version>3.0.0-SNAPSHOT</version>
Kept Infinispan as 5.0.0.FINAL, but saw the same on 5.1.0-SNAPSHOT
Now I get a failure to load; apparently, something else changed:
java.lang.NoSuchMethodError:
org.infinispan.config.InfinispanConfiguration.newInfinispanConfiguration(Ljava/lang/String;Ljava/lang/String;Lorg/infinispan/config/ConfigurationBeanVisitor;Ljava/lang/ClassLoader;)Lorg/infinispan/config/InfinispanConfiguration;
at
org.hibernate.ogm.datastore.infinispan.impl.CacheManagerServiceProvider.createCustomCacheManager(CacheManagerServiceProvider.java:126)
at
org.hibernate.ogm.datastore.infinispan.impl.CacheManagerServiceProvider.start(CacheManagerServiceProvider.java:80)
at
org.hibernate.ogm.metadata.GridMetadataManager.sessionFactoryCreated(GridMetadataManager.java:55)
at
org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:478)
at
org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1872)
at
org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:906)
at
org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:57)
at
org.hibernate.ogm.jpa.HibernateOgmPersistence.createEntityManagerFactory(HibernateOgmPersistence.java:99)
at
javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:63)
I'll clear the m2 cache tomorrow & try again, and if that fails I guess
I'll have to hit the SCM :)
-- Cyrille
4:57 p.m.
2011/8/12 Cyrille Chépélov <cyrille(a)chepelov.org>:
Le vendredi 12 août 2011 à 15:18 +0100, Sanne Grinovero a écrit :
Hi Cyrille,
5.0.0.FINAL was just released last week, and unfortunately introduced
a last minute API change which broke compatibility with OGM/Alpha2.
OGM master works fine now as it was a trivial fix, and I've deployed
an updated SNAPSHOT version, please try that one!
Not sure why it looked like to boot in your case.. you should have
seen a stacktrace at startup mentioning that Infinispan couldn't be
started,
please check your logs too.
Thanks Sanne,
Infinispan appears to boot. When configuring a GUI to talk to the app, I can
see both nodes talking to each other, and no log messages to the contrary
seem to happen.
Just tried with hibernate-ogm as such:
<version>3.0.0-SNAPSHOT</version>
Kept Infinispan as 5.0.0.FINAL, but saw the same on 5.1.0-SNAPSHOT
Now I get a failure to load; apparently, something else changed:
java.lang.NoSuchMethodError:
org.infinispan.config.InfinispanConfiguration.newInfinispanConfiguration(Ljava/lang/String;Ljava/lang/String;Lorg/infinispan/config/ConfigurationBeanVisitor;Ljava/lang/ClassLoader;)Lorg/infinispan/config/InfinispanConfiguration;
at
org.hibernate.ogm.datastore.infinispan.impl.CacheManagerServiceProvider.createCustomCacheManager(CacheManagerServiceProvider.java:126)
at
org.hibernate.ogm.datastore.infinispan.impl.CacheManagerServiceProvider.start(CacheManagerServiceProvider.java:80)
at
org.hibernate.ogm.metadata.GridMetadataManager.sessionFactoryCreated(GridMetadataManager.java:55)
at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:478)
at
org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1872)
at
org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:906)
at
org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:57)
at
org.hibernate.ogm.jpa.HibernateOgmPersistence.createEntityManagerFactory(HibernateOgmPersistence.java:99)
at
javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:63)
I'll clear the m2 cache tomorrow & try again, and if that fails I guess I'll
have to hit the SCM :)
Hi,
yes please try again with a clean cache: the exception you just posted
is the one I was expecting you to see if using Alpha2 with Infinispan
5.0.0.FINAL.
Sanne
4:59 p.m.
Le vendredi 12 août 2011 à 15:57 +0100, Sanne Grinovero a écrit :
> I'll clear the m2 cache tomorrow & try again, and if
that fails I guess I'll
> have to hit the SCM :)
Hi,
yes please try again with a clean cache: the exception you just posted
is the one I was expecting you to see if using Alpha2 with Infinispan
5.0.0.FINAL.
Hi Sanne,
I've tried again with OGM 3.0.0.Alpha2-40-g9c833b5 + Infinispan
5.0.0.FINAL.
The system boots successfully, and InfinispanDialect.updateTuple() does
get called.
After a few more hours mazing through Infinispan's visitors, I can now
report success getting my first entities (and associates) to persist to
disk. This is a baby step, but a successful step nonetheless!
Thank you very much !
I understand JP-QL or criteria queries are for now out of reach.
Is there a way to find entities if not by their generated uuid, or to
write entities with an externally-provided UUID ? (either way would be
fine for me to proceed with the POC I'm attempting)
-- Cyrille
5:48 p.m.
Hi,
I'm glad you got it working.
Regarding queries, you can use it with Hibernate Search as we did in a
demo at JBoss World [1], that doesn't provide all power of relational
queries but can still deal with most needs (and full text queries as
well); the only thing you have to consider is to use
fullTextQuery.initializeObjectsWith(
ObjectLookupMethod.PERSISTENCE_CONTEXT,
DatabaseRetrievalMethod.FIND_BY_ID );
as described in the blog post, to avoid having Search load entities
using a query.
1 - http://in.relation.to/Bloggers/WhatYouDidNotSeeAtTheJBossWorld2011Keynote...
Sanne
2011/8/15 Cyrille Chépélov <cyrille(a)chepelov.org>:
Le vendredi 12 août 2011 à 15:57 +0100, Sanne Grinovero a écrit :
> I'll clear the m2 cache tomorrow & try again, and if that fails I guess
> I'll
> have to hit the SCM :)
Hi,
yes please try again with a clean cache: the exception you just posted
is the one I was expecting you to see if using Alpha2 with Infinispan
5.0.0.FINAL.
Hi Sanne,
I've tried again with OGM 3.0.0.Alpha2-40-g9c833b5 + Infinispan 5.0.0.FINAL.
The system boots successfully, and InfinispanDialect.updateTuple() does get
called.
After a few more hours mazing through Infinispan's visitors, I can now
report success getting my first entities (and associates) to persist to
disk. This is a baby step, but a successful step nonetheless!
Thank you very much !
I understand JP-QL or criteria queries are for now out of reach.
Is there a way to find entities if not by their generated uuid, or to write
entities with an externally-provided UUID ? (either way would be fine for me
to proceed with the POC I'm attempting)
-- Cyrille
2:58 p.m.
New subject: [OGM-8, OGM-21] initial "criteria query" search
Hi Sanne,
Le lundi 15 août 2011 à 16:48 +0100, Sanne Grinovero a écrit :
Regarding queries, you can use it with Hibernate Search as we did in
a
demo at JBoss World [1], that doesn't provide all power of relational
queries but can still deal with most needs (and full text queries as
well); the only thing you have to consider is to use
Well; the application for which I'm experimenting with OGM/Infinispan
requires a synchronous search behaviour (which is, once a write
transaction completes, subsequent 'read' transactions must show
immediately the modified state). A previous implementation of the
service currently struggles, because it attempts to expect this from
SOLR (meep! wrong). Eventually relying on Lucene again won't buy me much
here :)
As both OGM-21 (no JP-QL) and OGM-8 (no Criteria Queries either) block
me, and before temporarily retreating on JPA(Hibernate)+Postgres, I've
played with sketching a very early implementation of CQ support. Not
much, not properly tested, nothing, but enough to get a my single use
case somewhat working:
/* with
@Entity
public class Document {
@Id
@GeneratedValue(generator = "uuid")
@GenericGenerator( name="uuid", strategy = "uuid2")
String internalUuid;
@NaturalId
private String docuid;
public String title;
}
*/
CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<Document> cq = cb.createQuery(Document.class);
Root<Document> clRoot = cq.from(Document.class);
cq.select(clRoot).where(cb.equal(clRoot.get("docuid"), uid));
/* List<Document> docs = em.createQuery(cq).getResultsList(); */
List<Document> docs = TypedCriteriaQueryFactory
.createTypedQuery(em, cq).getResultList();
caveats:
* apparently, Infinispan's Distributed Execution Framework
requires the clustering mode to be "distribution";
"replication"
ought to be fine too, but the engine seems to have strong
opinion against this.
* only the simplest queries have a chance to work
* a full scan on the whole ENTITIES cache is going to happen on
every query. And then an individual load(by @Id) on each
matched entity.
* for the moment, this is implemented as external code, rather
than a proper patch. Hence a fairly ugly "ClandestineAccess"
class. I guess a more correct implementation will have to find a
better way to bounce from OgmEntityManager down to the
InfinispanDialect, but for now Session seems to have a fairly
strong opinion that the query world is about JDBC and HQL->SQL
translations only.
* Apparently, sometimes the ghost of a previous instance is
detected by Infinispan which then fails because of a remote
invocation error. I guess this is more an issue with eclipse
starting new sessions before killing the previous one.
With that said, I can now proceed!
-- Cyrille
3:30 p.m.
New subject: [OGM-8, OGM-21] initial "criteria query" search
Le mercredi 17 août 2011 à 14:58 +0200, Cyrille Chépélov a écrit :
[snip]
... attachment here:
http://www.chepelov.org/cyrille/files/xpogm-01.tar.gz
-- Cyrille
4:58 p.m.
New subject: [OGM-8, OGM-21] initial "criteria query" search
Hi Cyrille,
thank you that's very interesting, I'll have a look into your code.
Some more comments inline:
2011/8/17 Cyrille Chépélov <cyrille(a)chepelov.org>:
Hi Sanne,
Le lundi 15 août 2011 à 16:48 +0100, Sanne Grinovero a écrit :
Regarding queries, you can use it with Hibernate Search as we did in a
demo at JBoss World [1], that doesn't provide all power of relational
queries but can still deal with most needs (and full text queries as
well); the only thing you have to consider is to use
Well; the application for which I'm experimenting with OGM/Infinispan
requires a synchronous search behaviour (which is, once a write transaction
completes, subsequent 'read' transactions must show immediately the modified
state). A previous implementation of the service currently struggles,
because it attempts to expect this from SOLR (meep! wrong). Eventually
relying on Lucene again won't buy me much here :)
Agreed that Lucene will introduce an overhead/slowdown during
insertions, but we're still able to provide both synchronous updates
and transactionality to some extent (currently failing to write to the
Lucene index won't rollback the transaction).
Also with Hibernate Search 4 coming quickly (1-2 months, an alpha very
soon) we're going to minimize write latency to the extreme, you won't
ever need to wait for merge operations, optimizations or disk flushes.
As both OGM-21 (no JP-QL) and OGM-8 (no Criteria Queries either) block me,
and before temporarily retreating on JPA(Hibernate)+Postgres, I've played
with sketching a very early implementation of CQ support. Not much, not
properly tested, nothing, but enough to get a my single use case somewhat
working:
/* with
@Entity
public class Document {
@Id
@GeneratedValue(generator = "uuid") @GenericGenerator(
name="uuid",
strategy = "uuid2")
String internalUuid;
@NaturalId
private String docuid;
public String title;
}
*/
CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<Document> cq = cb.createQuery(Document.class);
Root<Document> clRoot = cq.from(Document.class);
cq.select(clRoot).where(cb.equal(clRoot.get("docuid"), uid));
/* List<Document> docs = em.createQuery(cq).getResultsList(); */
List<Document> docs = TypedCriteriaQueryFactory
.createTypedQuery(em, cq).getResultList();
caveats:
that's awesome, I would love to see you adding tests and polishing
enough to be included in OGM.
apparently, Infinispan's Distributed Execution Framework requires the
clustering mode to be "distribution"; "replication" ought to be fine
too,
but the engine seems to have strong opinion against this.
only the simplest queries have a chance to work
a full scan on the whole ENTITIES cache is going to happen on every query.
Please open a feature request on Infinispan, I agree we need a
consistent API for both clustering modes,
and even LOCAL should be supported, at least to simplify testing. Also
please post here a reference, I'd be glad to vote and follow the
issue.
And then an individual load(by @Id) on each matched entity.
for the moment, this is implemented as external code, rather than a proper
patch. Hence a fairly ugly "ClandestineAccess" class. I guess a more correct
implementation will have to find a better way to bounce from
OgmEntityManager down to the InfinispanDialect, but for now Session seems to
have a fairly strong opinion that the query world is about JDBC and HQL->SQL
translations only.
I know :( that should change soon anyway, even though our
initial HQL
translation plans where towards using Lucene, we'll want to support
the Distributed Executor too, better even both.
Apparently, sometimes the ghost of a previous instance is detected
by
Infinispan which then fails because of a remote invocation error. I guess
this is more an issue with eclipse starting new sessions before killing the
previous one.
Yes making sure an Infinispan CacheManager is completely killed is
tricky. Make sure you shutdown the SessionFactory, when using OGM, or
if starting instances directly for test purposes have a look into
TestUtils in Infinispan: there are some methods used to make sure a
CacheManager is dead dead dead.. always tricky to deal with these
highly available systems :)
With that said, I can now proceed!
-- Cyrille
Sanne
4629
days inactive
4634
days old
8 comments
2 participants
participants (2)
-
Cyrille Chépélov -
Sanne Grinovero