Thanks that explains why I was missing the correlation.
To avoid the transaction manager to kill our indexing process, I guess
our only answer today is to reconfigure the transactions manager to
use larger timeouts?
That's quite limiting, especially as it requires to change it
globally; ideally I'd want to ping the TM regularly to let it know
we're still busy (and doing fine) ?
I couldn't find a method to do that by looking at the standard
javax.transaction API, so I'm wondering if we should take advantage of
some proprietary extensions.
Other than that, on the standard API I see we could set the TX timeout
for this specific transaction; we should probably add a new option to
the MassIndexer API to have the user suggest a
very-high-but-reasonable timeout?
Sanne
On 23 December 2013 10:09, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
Sorry late here.
OptionallyWrapInJTATransaction is not about timeout. It's about
explicitly starting a JTA transaction like a CMT entity bean would to so
that Hibernate ORM does not complain.
On Mon 2013-11-11 17:29, Sanne Grinovero wrote:
> Hi Emmanuel,
> in case you get very bored at Devoxx :)
>
> I remember you implementing a quite complex fix for my initial
> MassIndexer which involved avoiding the transactions we use from
> timing out.
> This is probably more than a year old, but there is a user on the
> forums now using 4.4.0.Final and having a suspiciously similar
> problem:
>
>
https://forum.hibernate.org/viewtopic.php?f=9&t=1029562
>
>
> I've looked into our code, but I'm not understanding how the class
> org.hibernate.search.batchindexing.impl.OptionallyWrapInJTATransaction
> is supposed to prevent the transaction from timing out?
>
> Do you have any idea on the problem?
> I recently had to apply some refactoring so I might have introduced a
> regression but I need another pair of eyes.
>
> Tia,
> Sanne