[Tracked now as HSEARCH-1474]
thanks that's an interesting path to explore; still one problem is
consistency during on going changes: the way it works today most of
the work is processed by parallel and short lived transactions, but
the main stream of primary keys is a forward-only scrollable whic
I guess you could do it mostly transparently for the user.
Set a reasonably high timeout like say 2 mins, then every n operation look how
much
you've consumed. If you are close to the limit, you commit and restart a
transaction.
So your option would be semi public.
hibernate.search.massindexer.tr
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'
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 :)
>
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
