Sanne, I wonder if that could be used as a way to get rid of the weak
identity hash map we have in Hibernate Search. (I think we got rid of
all ThreadLocal already).
Steve, do you think I could (ab)use these as Session level cache? I
think OGM could benefit from such feature in a couple of situati
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 :)
>
Am 23.12.2013 10:55 schrieb "Emmanuel Bernard" :
>
> Sanne, I wonder if that could be used as a way to get rid of the weak
> identity hash map we have in Hibernate Search. (I think we got rid of
> all ThreadLocal already).
>
> Steve, do you think I could (ab)use these as Session level cache? I
> th
On Mon 2013-12-23 11:37, Gunnar Morling wrote:
> Am 23.12.2013 10:55 schrieb "Emmanuel Bernard" :
> >
> > Sanne, I wonder if that could be used as a way to get rid of the weak
> > identity hash map we have in Hibernate Search. (I think we got rid of
> > all ThreadLocal already).
> >
> > Steve, do y
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'
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
[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
Hi everyone,
I am writing to make a proposal to refactor the Configuration class as an
interface and and implementation for the reason below.
It would allow third-party developers as myself to use proxies and
decorators with default configuration.
For example, in groovy.grails they extend the Co
This Configuration class is being deprecated in 5.0, take a look of the new
interface :)
org.hibernate.metadata package:
* MetadataSources
* Metadata
* MetadataBuilder
* SessionFactoryBuilder
On Dec 24, 2013, at 1:45, Andrey Polyakov wrote:
> Hi everyone,
>
> I am writing to make a proposal
