The highlight is that it's using Apache Lucene 5.2.1 now.
As I mentioned on the blog post, it would be great if someone could
step up and help us by running some benchmarking and performance
I want to introduce myself and a new database back-end worker, me and
another guy have build for hibernate search. I already had some initial
talk with Sanne regarding if this could be interested to the hibernate
I have been working with Hibernate Search from some time and actually done
various small custom modification to search since 3.x, especial around
running in a cluster and indexing. To make a long story short when we
upgraded Hibernate search we thought it would be ideal to use a SQL
database as storage for lucene workers for 3 main reasons.
- The database was shared between the nodes
- The workers was persistent in case of a node crash.
- No master/slave
*In some way it’s very similar to the JMS back-end worker, where the user
also have to implement a MDB that process the workers. In our case they
will have to implement a job using something like quartz or a timer
*We are using JPA as persistence layer for the database, even it’s a fairly
simple entity we persistent, but it make sense for supporting various
databases and schema update out of the box. We have tried to make it’s as
easy as possible to set-up by minimizing the number of properties, and it’s
all configurable from the persistence.xml*
*The actually work can* be *find here
*So based on this introduction and the code, is this something you could
use? (of course with the modification it requires to follow the design,
style, docs etc for the search)*--
Could someone give me a one-sentence definition of what's the method
named above is supposed to do? Its name gives me some ideas, but I'd
love to see a proper documentation of the intended behaviour there.
With a proposed TM level listener, we will have an SPI for notification
of when application threads associated with a JTA transaction, become
disassociated with the transaction (tm.commit/rollback/suspend time).
Having this knowledge in a synchronization callback, can determine
whether the persistence context should be cleared directly from the
Synchronization.afterCompletion(int) call or should be deferred until
the transaction is disassociated from the JTA transaction.
This idea is based on a TM level listener approach that Tom Jenkinson
 suggested. Mike Musgrove has a "proof of concept" implementation of
the suggested changes . I did some testing with  to see if the
improvement helps with clearing entities that might still be in the
persistence context after a background tx timeout.
I'm wondering if in the Hibernate ORM
Synchronization.afterCompletion(int status) implementation, in case of
tx rollback, if we could defer the clearing of the Hibernate session to
be handled by the JtaPlatform. This could be setup at
EntityManager.joinTransaction() time (if a new property like
"hibernate.transaction.defer_clear_session" is true). Perhaps via a
JtaPlatform.joinTransaction(EntityManager) registration call?
In working through the document overhaul I ran across the following passage
in the JPA specification:
The persistent state of an entity is represented by instance variables,
which may correspond to JavaBeans properties. An instance variable must be
directly accessed only from within the methods of the entity by the entity
instance itself. Instance variables must not be accessed by clients of the
entity. The state of the entity is available to clients only through the
entity’s methods—i.e., accessor methods (getter/setter methods) or other
(from section "2.1 The Entity Class" in the JPA 2.1 specification). Notice
that the spec explicitly calls out that even with field access the
expectation is that the application still access the state via methods. In
other words our concept of "extended enhancement" is actually beyond the
I thought we had discussed this once upon a time, but I could not find any
email. In overhauling the documentation I ran across our long-standing
recommendation that all associations be defined in metadata as lazy. JPA
of course came along said that for to-one associations the default should
Do we want to add a setting to allow folks to alter these defaults? I know
that's tough in terms of portability between providers, but that is
ultimately the user's choice.