[Hibernate Search] Database back end worker
by Flemming Harms
Hey guys
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
search project.
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
service. *
*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
https://github.com/umbrew/org.umbrew.hibernate.database.worker.backend
<https://github.com/umbrew/org.umbrew.hibernate.database.worker.backend>*
*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)*--
Kind regards
Flemming Harms
10 years, 1 month
new proposal for tx timeout handling using transaction DISASSOCIATING event notification...
by Scott Marlow
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
[1] suggested. Mike Musgrove has a "proof of concept" implementation of
the suggested changes [2]. I did some testing with [3] 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?
Thoughts?
Scott
[1] https://developer.jboss.org/thread/252572?start=45&tstart=0
[2]
https://github.com/mmusgrov/jboss-transaction-spi/blob/threadDisassociati...
[3]
https://github.com/scottmarlow/wildfly/tree/transactiontimeout_clientut_n...
10 years, 1 month
Bytecode enhancement and field-access
by Steve Ebersole
In working through the document overhaul I ran across the following passage
in the JPA specification:
<quote>
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
business methods.
</quote>
(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
spec.
10 years, 1 month
Default fetching
by Steve Ebersole
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
eager.
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.
10 years, 1 month
