Question,
Do we have one cache for all indexes (directories) or one per directory?
I feels wrong to see this configuration not scoped per index
hibernate.search.default.directory_provider
blah.blah.InfinispanDirectoryProvider
hibernate.search.default.infinispan_conf com.acme.CacheFactoryImpl
hi
Yes but Lukasz do see data disappearing (see initial email). So there
is a problem somewhere?
Lukasz, can you maybe share the code and test with us so someone can
have a closer look with you?
Emmanuel
On 13 août 09, at 18:56, Sanne Grinovero wrote:
> I am not an expert on this part of Lucene
+1
very nice!
but having the same property key for both classname or xml? And will
there be a working default (like auto-discovery) ?
2009/8/14 Łukasz Moreń :
> I was thinking that maybe we can expose full conf options. Infinispan
> supports programmatical and xml ways to configure cache.
> To a
I am not an expert on this part of Lucene, but it looks like to me
that the IndexWriter is the "driver/coordinator", and it's decisions
are affected by a pluggable MergeScheduler; they do stuff on the
internal buffers of the IndexWriter (dequeue the pending segments to
be written to the index), but
I was thinking that maybe we can expose full conf options. Infinispan
supports programmatical and xml ways to configure cache.
To achieve first one, could be created some interface with factory method
that returns cache. User can implement that and create cache as he wants.
Something like that:
Yes, right, MergeSchedulers.
2009/8/14 Sanne Grinovero
> what are these "other" threads? Are you speaking about the MergeSchedulers?
>
> 2009/8/13 Łukasz Moreń :
> > IndexWriter processes index update and delegates some job to other
> > threads and waits when they finish. These "other" threads w
what are these "other" threads? Are you speaking about the MergeSchedulers?
2009/8/13 Łukasz Moreń :
> IndexWriter processes index update and delegates some job to other
> threads and waits when they finish. These "other" threads works on
> data modified
> in IndexWriter transaction. So I think if
IndexWriter processes index update and delegates some job to other
threads and waits when they finish. These "other" threads works on
data modified
in IndexWriter transaction. So I think if I use transaction per
thread, "others" would not see data modified by IndexWriter until
commit.
2009/8/13, E
Ah I thought it was using multiple threads because of your mass
indexing. I did not know some threads were span specifically for the
Infinispan directory.
On 13 août 09, at 17:34, Sanne Grinovero wrote:
> Hi Łukasz,
> what is your usage of these threads? did you consider using one
> transacti
It's a bit complex but the Lucene IndexWriter works better if you can
inject what has to be indexed in a multi threaded way because
analyzing the data before writing it to the index can be heavy.
The IW does rely on what is called a Directory (implemented by
Infinispan in this case).
On 13 a
Hi Łukasz,
what is your usage of these threads? did you consider using one
transaction per thread?
Sanne
2009/8/13 Łukasz Moreń :
> Newly created threads were not associated with any transaction, so I
> suppose it was a problem. Sharing transaction between threads seems to
> be a good solution.
>
Newly created threads were not associated with any transaction, so I
suppose it was a problem. Sharing transaction between threads seems to
be a good solution.
Thanks for help!
2009/8/13, Jason T. Greene :
> Correct. Also there could be read races as well, so if you are going to
> share a tx betwe
Heads up that I will be doing the first beta release for 3.5 tomorrow.
In support of that I will also be cutting a beta release of
org.hibernate.java-persistence:jpa-api.
Cheers.
--
Steve Ebersole
Hibernate.org
___
hibernate-dev mailing list
hibernat
Modifying a transaction means applying muations (like SQL INSERT /
UPDATE / DELETE) to the transactional resource?
On 13 août 09, at 15:07, Jason T. Greene wrote:
> When using transactions, the context is bound to the transaction,
> and you can move a transaction between threads. However, you
Could it be that you are not using the same transaction between
different threads (ie you physically start different ones or different
"Infinispan contexts")?
Infini guys, do you support transactional operation spanning several
concurrent threads?
On 13 août 09, at 14:04, Łukasz Moreń wrote
I've tried with JBoss AS transaction manager and JBossStandaloneTM.
The result is this same in all cases - error during merge.
2009/8/12, Emmanuel Bernard :
> Ok I understand better now.
> Do your tests in JBoss AS with it's decent transaction manager
> (infinispan should have a config for it)
> F
I'll do this today;
Łukasz, thanks for the status update!
Sanne
2009/8/12 Emmanuel Bernard :
> If someone in the search team could take Lukasz's patch from last
> month (in the mailing list) and apply it with a quick final review
> that would be great. I wanted to do it but I have been swamped at
On 08/13/2009 01:27 PM, Galder Zamarreno wrote:
> Hi Brian,
>
> Of my original email, there's a section that I don't think has been
> answered yet
>
> On 08/04/2009 10:37 AM, Galder Zamarreno wrote:
>> Finally, a question to the list, specially for Brian/Steve who worked on
>> the JBC2/3 integrat
Hi Brian,
Of my original email, there's a section that I don't think has been
answered yet
On 08/04/2009 10:37 AM, Galder Zamarreno wrote:
> Finally, a question to the list, specially for Brian/Steve who worked on
> the JBC2/3 integration layer:
>
> - Do we need a similar timestamp region local
19 matches
Mail list logo
