Am I correct in my interpretation that Hibernate 4 no longer supports
interchangeably being able to use either the Hibernate transaction
facade(session.beginTransaction) vs. UserTransaction or CMT?
I say this because it appears that I always must call
session.beginTransaction() when configured to use
JTATransactionFactory, in order to have JtaTransaction->local status
of active. If local status is not active Hibernate makes no attempt
to check the provided JtaPlatform if there is a user transaction in
process and blows up whenever trying to execute any changes to the db.
In 3.x this worked fine since
JTATransactionFactory->isTransactionInProgress always tried to find
the configured transaction manager and checked the transaction status
properly. But in 4.x I'm not seeing how local status gets set to
active to prevent a blow up unless I both call userTransaction.begin()
AND session.beginTransaction()... The same problems exist when
interacting through the EntityManager API.
Even in the ManagedDrivingTest it looks like it is assumed that the
client will call session.beginTransaction() after either a CMT or BMT
has been started. I would cut over to using the Hibernate facade
exclusively, but now it throws 'nested transactions not supported' if
beginTransaction is invoked multiple times. The Spring
PlatformTransactionManager API deals with multiple layered invocations
more gracefully, so I've mostly used that in the past for programmatic
transaction management. But regardless, looking at the source there
seems to be a new requirement to always have
session.beginTransaction() invoked in application code.
I've spent days trying to figure out if I've made a configuration
mistake, and at this point I'm at the conclusion that either Hibernate
behavior in this area was intentionally changed, or that this is a
bug. If its a bug it would probably break a lot of apps upgrading
from 3.x to 4.x that use programmatically controlled transactions. So
I thought I'd just reach out on the mailing list for clarification, or
to have an obvious misconfiguration or misunderstanding corrected.
For more info on my JTA config there is a forum post I made that is
unrelated(realized my error on that topic) here:
I'm in process to migrate an application from an old Hibernate Search version
to the latest one. We have been used own implementation of Worker.
In the old Hibernate Search version it was possible to define own implementation
of Worker using the property "hibernate.search.worker.scope". But it seems not
possible to do it in the latest version although the Hibernate Search Guide suggest
to use this property.
After studying the sources of Hibernate Search I have found that the property
to be used is "worker.scope". This change was introduced with the work on
the issue HSEARCH-761.
Could you please verify what is the right property name and either correct the
Hibernate Search Guide or change the property name in the Environment
class to the old one.
Thanks in advance!
I am new to hibanate,Stuts and Tile. Now I want to get selected
specified columns. I have mention the code below. It is not working.
List<SelelctItemList> list = new ArrayList<SelelctItemList>();
Query query = (Query) session.createQuery("select
from service_uses as su INNER JOIN stocks as s ON su.item_id=s.item_id
where service_id="+ serviceId);
list = ((org.hibernate.Query) query).list();
I've converted the seam hotel booking JPA example to use Hibernate OGM,
specifically the MongoDB dialect, and documented what needed to be done
on the wiki. The instructions and code should be fairly relevant to the
Infinispan dialect too.
I did encounter a few issues doing this so I hope the instructions will
be useful to others. The main change is that the queries needed
converting from criteria queries to Hibernate search/lucene.
The code is available on my github:
Let me know if you spot any errors/improvements in the wiki page or have
any fixes to the code.
Sorry for posting to the developers list, I have tried all other
places dedicated to end-user support, however it seems the question is
too in-depth :/
Is it possible to disable prepared statement caching for batched
fetching, so I end up with a single query in the <
default_batch_fetch_size case only instead of the fixed-size batch
loading hibernate does by default?
If its not configureable, I would be really grateful for a pointer to
the source where that caching and sub-batch-by-sub-batch loading is
I am latency bound with a low-loaded postgresql-server, so I would be
happy if I could trade lower server load with less roundtrips.
Thank you in advance, Clemens
Strong, I had to kill hibernate-core-master-matrix job #242. It had
been hanging for the last 8+ hours without every even having started any
of the individual matrix builds.
Is there any way to tell why it has hanging?
On May 4, 2012, at 1:51 PM, Steve Ebersole wrote:
> As for perf issues OGM uncovered in ORM... First, none of those involved anything close to the discussion here; they dealt mostly with small things (like hashCode caching) that became big because of size of scale. Second, thats actually exactly how you should discover and treat perf issues.
Right, especially the second sentence.