ServiceRegistry naming
by Steve Ebersole
Currently we utilize 3 different ServiceRegistry types within Hibernate
and I wanted to hopefully get some consensus on their names.
1) org.hibernate.service.internal.BootstrapServiceRegistryImpl. It
contains services that have to be known up front. Currently this is
limited to ClassLoaderService and IntegratorService. Personally I think
this one is already perfectly named per its intent/purpose.
2) org.hibernate.service.internal.BasicServiceRegistryImpl. The naming
of this one has caused some confusion for at least one person I know.
And I agree that the naming here is not best. Some other names proposed
have been "standard service registry" or "main service registry". This
is the main registry in that it holds most of the services. It has the
bootstrap registry as its parent, and the
SessionFactoryServiceRegistryImpl uses this as its parent.
3) org.hibernate.service.internal.SessionFactoryServiceRegistryImpl.
This is responsible for holding services that need access to the
SessionFactory during their init. Again, I think this is a good name
for its function, but am open to other suggestions. BTW, currently this
only includes the event listener service though I see this expanding a
little as we finish up the metamodel changes to include a few more services.
A related discussion, if we decided to rename any of these, is whether
that renaming warrants another CR release.
--
steve(a)hibernate.org
http://hibernate.org
14 years, 2 months
Refactoring in progress
by Sanne Grinovero
Hi all,
I'm working on
HSEARCH-677 Isolate Hibernate Core dependency to make Hibernate Search
fully standalone
it's affecting the position of many files, please avoid making changes
to files which are related to the integration with Hibernate core*,
and as always avoid any change not directly related to an issue you're
working on.
*(such as Session and Query implementors and extensions, core event listeners)
Cheers,
Sanne
14 years, 3 months
[search] Problems w/ JGroupsCommonTest
by Hardy Ferentschik
Hi,
does anyone else have problems w/ JGroupsCommonTest? It fails every few
test runs w/o
apparent reason. There is no exception, just a failing assertion. Instead
of two query
results none are returned.
I am at loss what's going on? Any JGroups interna maybe?
--Hardy
14 years, 3 months
Using AS7 prepared Statement caching and Hibernate 4.0.0.Beta4 + 4.0.0.Beta5
by Scott Marlow
https://issues.jboss.org/browse/AS7-1461 reflects a problem reported by
two users. One user reported, that in a transaction that included
multiple different entities being created, that Hibernate is trying to
use a closed prepared statement.
My question at this point is, what would happen if the AS7 prepared
statement cache were to close a prepared statement during a transaction.
For example, assuming that the prepared statement cache was configured
to a very low limit, like two. After two unique sql statements are in
the prepared statement cache, when a third unique sql statement is
created, one of the two cached statements will be closed. Could
Hibernate be holding onto one of these cached prepared statements (for
reuse in the transaction) that are closed?
Example execution order from user report:
1. insert into ASSEMBLIES (NAME, A_ID) values (?, ?)
2. other sql statements are executed.
3. insert into ASSEMBLIES (NAME, A_ID) values (?, ?)
4. other sql statements are executed.
5. At this point, I believe that "insert into ASSEMBLIES (NAME, A_ID)
values (?, ?)" could be aged out of the AS7 prepared statement cache.
6. "insert into ASSEMBLIES (NAME, A_ID) values (?, ?)" fails to execute
because of error
"com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException:
No operations allowed after statement closed"
For my local testing, I'm using H2 and get error
"org.h2.jdbc.JdbcSQLException: The object is already closed [90007-145]"
Does/should Hibernate check the prepared statement to see if its have
been closed before its reused in a transaction? Or should users disable
the AS7 prepared statement cache (current workaround)?
If Hibernate is currently checking if the prepared statement is closed
before reusing it, I must of missed that code in my inspection.
At this point, I'm still trying to find the root cause and answer the
above question as well.
Scott
14 years, 3 months
Re: [hibernate-dev] [HSearch] CI and build on Windows
by Emmanuel Bernard
Would have a subset of tests to run (non sensitive ones) help for these false positive?
On 21 sept. 2011, at 15:17, Sanne Grinovero wrote:
> not as far as I know. But even if we had, all CI builds are failing
> since a long time because of the performance issues in the lab so we
> wouldn't have spotted it.
>
> Sanne
>
> On 21 September 2011 14:12, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
>> Hi all,
>> Do we have a CI build on Windows for Hibernate Search 4?
>>
>> We should have spotted the resource loading issues with Avro issue much earlier.
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
14 years, 3 months
[HSearch] CI and build on Windows
by Emmanuel Bernard
Hi all,
Do we have a CI build on Windows for Hibernate Search 4?
We should have spotted the resource loading issues with Avro issue much earlier.
14 years, 3 months
[search] FieldBridge API change re-visited (HSEARCH-904)
by Hardy Ferentschik
Hi,
sorry to bring this issue up again, but when starting the refactoring for
this issue (taking the approach
to make the bridge stateful) I noticed a problem. We thought that we could
introduce
FieldBridge#initalize(String fieldName, LuceneOptions options)
while removing the same parameters from the set method. The assumption was
that LuceneOptions are constant
for a given field. It turns out this is not the case. Due to dynamic
boosting the boost factor can actually
change on each call to set.
The question is what to do now?
1. Just have FieldBridge#initalize(String fieldName) and keep the
LuceneOptions in set?
2. Keep the stateless interface, but change set to
Iterable<String> set(String name, Object value, Document document,
LuceneOptions luceneOptions);
3. Try to find a way which does not require the changing LuceneOptions.
See also comment on the Jira issue.
Thoughts?
--Hardy
14 years, 3 months
