Work on HHH-3110
by Les Hazlewood
Hi guys,
It has been a while since I've talked to most of the Hibernate team -
I hope all is well with everyone. I can say that I miss that I miss
working with the people, not so much the consulting travel :-P
Anyway, lemme get to business.
I upgraded from 3.2.5 to 3.2.6 and started getting exceptions about
JNDI. The company I'm working with uses Atomikos standalone
transaction manager outside of a JEE environment (no JNDI necessary),
I found this issue that exactly describes what I'm seeing:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3110
It was interesting to see from many posts on the web that many other
people are seeing the same issue, BTM, Jotm, Atomikos users, etc...
So, I started thinking, and communicated with Chris since the issue
was assigned to him. Here's a summary:
Les: I want to make some architectural adjustments to the
org.hibernate.transaction.JTATransaction implementation that would
work with or without JNDI, but be fully backwards compatible.
Any objections to me assigning the issue to myself?
Chris: I have an objection only insomuch as JTA implies JNDI
availability. Open up this issue on hibernate-dev and let's flesh it
out with Steve. I think the right solution is to provide an additional
implementation that uses JOTM directly, as suggested by Felix on the
JIRA case.
So, here I am.
The issue with JTATransaction is that it acquires the the
UserTransaction object via a JNDI lookup. If JNDI isn't being used,
we have the exception.
The proposed solution is to create an AbstractJTATransaction that does
exactly what the current implementation does, but abstracts the
UserTransaction lookup to subclasses.
Then JTATransaction would subclass AbstractJTATransaction and
implement the default JNDI lookup logic as exists today.
A new class, say a StandaloneJTATransaction would subclass
AbstractJTATransaction and acquire it via a different mechanism -
probably the TM-specific TransactionManagerLookup implementation looks
it up first and then passes it in the StandaloneJTATransaction
constructor.
Anyway, this would be fully backwards compatible because the
JTATransaction implementation would retain the same API and
functionality. It would just support non-JNDI environments very
cleanly and the TransactionManagerLookup implementation, which is
already TM-specific, would know what to do based on if it requires
JNDI or not.
So what do you think? Can I make this change in my local environment
and upload the patch to the issue to see how you guys like it? It
would make a lot of users (including me ;) ) quite happy, while still
retaining the JNDI defaults as expected by JTA.
Cheers!
Les
16 years, 1 month
JBoss Cache Searchable interfaces
by Manik Surtani
Hi guys - a few comments on the public interfaces of SearchableCache -
1) IMO, I think that the SearchableCache.createQuery() method should
*not* return a FullTextQuery, but instead a JBCS-specific CacheQuery
interface with a subset of the methods in FullTextQuery.
I think the only methods in FullTextQuery that are relevant and that
should be carried across to CacheQuery are:
* list()
* iterator();
* setFirstResult(int i);
* setMaxResults(int i);
* setFetchSize(int i);
* getResultSize();
* setSort();
I think all of the rest - such as filters, criteria and projections -
are irrelevant to a query on a cache. WDYT? Emmanuel?
2) Also, rather than implement FullTextQuery.scroll() to return a
ScrollableResults instance, I'd rather that iterator() returns an
instance of a new interface, QueryResultsIterator, which extends
j.u.ListIterator. This gives us the ability to scroll back and forth
over a result set, and we could add additional methods to jump to a
specific point in the result set and helpers such as isLast(),
isFirst(), isBeforeLast(), isAfterFirst(), first(), last(),
afterFirst(), beforeLast().
I think that any benefit of a scrollable result set window preventing
loading unnecessary objects from a DB are lost when your backing store
is a cache and the objects are in memory anyway. And besides, any
further optimisations can be in the iterator implementation, such as
just maintaining a list of CachedEntityIds (a composite of Fqn and
key) and fetching the objects from the cache lazily, as required.
Also, with the above, 2, we don't leak any Hibernate or Hibernate
Search interfaces into the user API which again IMO is a good thing.
Thoughts, comments?
Cheers
Manik
On 24 Jun 2008, at 11:47, Navin Surtani wrote:
>
>
> Begin forwarded message:
>
>> From: Emmanuel Bernard <emmanuel(a)hibernate.org>
>> Date: 24 June 2008 08:19:03 BST
>> To: Navin Surtani <navin(a)surtani.org>
>> Subject: Re: More hibernate questions
>>
>> Scroll is more important than iterate because it allows to read
>> objects s a window and get rid of them on a regular basis without
>> facing out of memory exception.
>> I think it's used more often than iterate
>>
>> On Jun 23, 2008, at 18:17, Navin Surtani wrote:
>>
>>> Hey again -
>>>
>>> I have a CacheQueryImpl class that extends the FullTextQuery
>>> interface and I am implementing the methods as similar as possible.
>>>
>>> A couple of problems occur when you are taking in and using
>>> certain Hibernate objects for example. A problem lies with the
>>> scroll() method. I think it is very similar to the iterate()
>>> method and does not need to be implemented in CacheQueryImpl. Do
>>> you know if Hibernate users generally use this method and find
>>> that they need it? If so then I will try and implement it
>>> otherwise then I will just make it throw an exception.
>>>
>>> Thanks again :)
>>> Navin.
>>
>
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
16 years, 1 month
Search: how to define hints for batch indexing
by Sanne Grinovero
Hi everyone,
I am working on batch indexing for Hibernate Search, I would like to define
a new annotation
to set the needed "hints" for the process "@BatchIndexingHints"; one of the
hint parameters is "which HQL query should I use?"
The query is optional and I can fallback to a simple scrolling criteria,
also this query should
not affect the functionality, only a performance hint to define join fetch
collections needed for indexing.
The options we found (speaking with Emmanuel) are 4:
1)don't ask for a query but for the name of a named query.
I don't like this one as the definition of a named query is too flexible,
e.g. I know for sure the
"readonly=true" is preferable for my purpose. Also this query is going to be
created only once per
thread during an indexing process, so I don't foresee a considerable
performance boost.
Additionally the name of the NamedQuery would be redundant as I would be the
only user (probably).
2)define the HQL to load all entities in @BatchIndexingHints.
3)Let the user only define a list of Strings, naming the properties to be
eagerly loaded;
I would add these using .setFetchMode("prop1", FetchMode.EAGER) on the base
Criteria.
This would be nice as we could be sure the users can't add some restriction
or load
the wrong entity, making it more safe.
But I wonder if we are loosing too much flexibility in this case.
4)don't tell anything at class level put add a boolean to desired fields,
something like
@Field(eagerInBatch=true) or @Field(InBatch=FetchType.EAGER)
(adding a property to existing annotation)
Besides the eagerly loading query the other parameters are 3 ints needed to
set the size
of 3 different ThreadPools which do the job at different stages; they are
here to provide
a nice per-entity default, but if I move them to a configuration property
and we
select option 4) I could avoid the new annotation.
some comments?
Sanne
16 years, 1 month
Re: [hibernate-dev] Immutable entities
by Steve Ebersole
Mutable entities should be creatable as well as deletable.
The difficulty with immutable and checking for changes (to see whether
we should throw an exception) is that of performance in the case of
simple reattachment of detached entities. This is less an issue in the
case of merge()/saveOrUpdateCopy(). But in the simple case reattachment
this would require a select to know the previous values. So for
consistency-sake (I assume) immutable="true" always just ignores any
potential changes.
We could certainly add a feature for the optional ability to perform the
checking (which I agree would be more desirable, probably, as a user).
--
Steve Ebersole
Project Lead
http://hibernate.org
steve(a)hibernate.org
Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.com
steve.ebersole(a)jboss.com
steve.ebersole(a)redhat.com
On Tue, 2008-06-24 at 13:05 +0200, Hardy Ferentschik wrote:
> On Mon, 23 Jun 2008 17:05:52 +0200, Steve Ebersole <steve(a)hibernate.org>
> wrote:
>
> > What happens if you remove the unecessary save() call after changing the
> > name?
>
> Same, same. The update gets ignore, but no exception is thrown.
>
> There is a ImmutableTest in the core and it seems to also not expect an
> Exception. However, as I mentioned in my other email - updating a mutable
> collection seems to throw an exception. I am also able to delete mutable
> entities. Is this correct?
>
> --Hardy
>
>
>
>
16 years, 1 month
Immutable entities
by Hardy Ferentschik
Hi there,
I am trying to figure out what should happen if I modify an entity marked
as @Immutable. Somehow I expected an exception to be raised, but nothing
seem to happen. I wrote this test case (the Country entity is marked as
@Immutable):
public void testImmutableEntity() throws Exception {
Session s = openSession();
Transaction tx = s.beginTransaction();
Country country = new Country();
country.setName("Germany");
s.persist(country);
tx.commit();
s.close();
try {
s = openSession();
tx = s.beginTransaction();
Country germany = (Country) s.get(Country.class, country.getId());
assertNotNull(germany);
germany.setName("France");
s.save(germany);
// s.delete(germany);
tx.commit();
s.close();
fail();
} catch (Exception e) {
log.debug("success");
}
}
The exception is never raised. The core documentation only says "Immutable
classes may not be updated or deleted by the application". It does not say
anything about what happens if one tries to do so. Should the above
testcase work or not?
Thanks,
Hardy
16 years, 1 month
[Hibernate Search] session.flushToIndexes()
by Emmanuel Bernard
I never liked the way we work around mass insertion and OOME today
hibernate.search.worker.batch_size has many drawbacks
- the value is not accessible programatically
- it applies to any operations regardless of mass indexing
- it is used 99% of the time in close conjunction with a % and
session.clear()
- the side effect is quite big as the index is "transactionally"
committed
To replace it, I introduced
session.flushToIndexes();
this method manually triggers changes in queue. It does not trigger an
hibernate core flush().
This seems more reasonable and will make the code safer.
WDYT? Better name?
--
Emmanuel Bernard
emmanuel(a)hibernate.org
http://in.relation.to
http://blog.emmanuelbernard.com
http://twitter.com/emmanuelbernard
16 years, 1 month
[Hibernate Search] session.flushToIndexes()
by John Griffin
Since the flush time now becomes accessible programmatically this is a
better additional alternative to just the batch flush.
+1 to not triggering a Hibernate core flush.
+1 to the name. It says exactly what it does.
John G.
-----Original Message-----
From: hibernate-dev-bounces(a)lists.jboss.org
[mailto:hibernate-dev-bounces@lists.jboss.org] On Behalf Of
hibernate-dev-request(a)lists.jboss.org
Sent: Saturday, June 21, 2008 10:00 AM
To: hibernate-dev(a)lists.jboss.org
Subject: hibernate-dev Digest, Vol 24, Issue 19
Send hibernate-dev mailing list submissions to
hibernate-dev(a)lists.jboss.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.jboss.org/mailman/listinfo/hibernate-dev
or, via email, send a message with subject or body 'help' to
hibernate-dev-request(a)lists.jboss.org
You can reach the person managing the list at
hibernate-dev-owner(a)lists.jboss.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of hibernate-dev digest..."
Today's Topics:
1. [Hibernate Search] session.flushToIndexes() (Emmanuel Bernard)
----------------------------------------------------------------------
Message: 1
Date: Sat, 21 Jun 2008 15:49:02 +0200
From: Emmanuel Bernard <emmanuel(a)hibernate.org>
Subject: [hibernate-dev] [Hibernate Search] session.flushToIndexes()
To: hibernate-dev(a)lists.jboss.org
Message-ID: <611FEB50-98B7-4BEE-B238-0A1168A07B9F(a)hibernate.org>
Content-Type: text/plain; charset="us-ascii"
I never liked the way we work around mass insertion and OOME today
hibernate.search.worker.batch_size has many drawbacks
- the value is not accessible programatically
- it applies to any operations regardless of mass indexing
- it is used 99% of the time in close conjunction with a % and
session.clear()
- the side effect is quite big as the index is "transactionally"
committed
To replace it, I introduced
session.flushToIndexes();
this method manually triggers changes in queue. It does not trigger an
hibernate core flush().
This seems more reasonable and will make the code safer.
WDYT? Better name?
--
Emmanuel Bernard
emmanuel(a)hibernate.org
http://in.relation.to
http://blog.emmanuelbernard.com
http://twitter.com/emmanuelbernard
16 years, 1 month
RE: hibernate-dev Digest, Vol 24, Issue 19
by John Griffin
Since the flush time now becomes accessible programmatically this is a
better additional alternative to just the batch flush.
+1 to not triggering a Hibernate core flush.
+1 to the name. It says exactly what it does.
John G.
-----Original Message-----
From: hibernate-dev-bounces(a)lists.jboss.org
[mailto:hibernate-dev-bounces@lists.jboss.org] On Behalf Of
hibernate-dev-request(a)lists.jboss.org
Sent: Saturday, June 21, 2008 10:00 AM
To: hibernate-dev(a)lists.jboss.org
Subject: hibernate-dev Digest, Vol 24, Issue 19
Send hibernate-dev mailing list submissions to
hibernate-dev(a)lists.jboss.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.jboss.org/mailman/listinfo/hibernate-dev
or, via email, send a message with subject or body 'help' to
hibernate-dev-request(a)lists.jboss.org
You can reach the person managing the list at
hibernate-dev-owner(a)lists.jboss.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of hibernate-dev digest..."
Today's Topics:
1. [Hibernate Search] session.flushToIndexes() (Emmanuel Bernard)
----------------------------------------------------------------------
Message: 1
Date: Sat, 21 Jun 2008 15:49:02 +0200
From: Emmanuel Bernard <emmanuel(a)hibernate.org>
Subject: [hibernate-dev] [Hibernate Search] session.flushToIndexes()
To: hibernate-dev(a)lists.jboss.org
Message-ID: <611FEB50-98B7-4BEE-B238-0A1168A07B9F(a)hibernate.org>
Content-Type: text/plain; charset="us-ascii"
I never liked the way we work around mass insertion and OOME today
hibernate.search.worker.batch_size has many drawbacks
- the value is not accessible programatically
- it applies to any operations regardless of mass indexing
- it is used 99% of the time in close conjunction with a % and
session.clear()
- the side effect is quite big as the index is "transactionally"
committed
To replace it, I introduced
session.flushToIndexes();
this method manually triggers changes in queue. It does not trigger an
hibernate core flush().
This seems more reasonable and will make the code safer.
WDYT? Better name?
--
Emmanuel Bernard
emmanuel(a)hibernate.org
http://in.relation.to
http://blog.emmanuelbernard.com
http://twitter.com/emmanuelbernard
16 years, 1 month
Hibernate for Perl
by Lee Standen
Hi All,
I was wondering what the Hibernate developers thought about supporting a
project to port Hibernate into Perl?
My company is looking to build a subset of the functionality that Hibernate
has in order to support a couple of our upcoming projects. It has been
suggested that we might get support from the business to make this an open
source project, allowing us to involve the community in further development.
That then opens the prospect of making this into a Hibernate port rather
than just another ORM.
Look forward to any responses :)
Thanks!
16 years, 1 month
