[hibernate-dev] [Search] making updates to the indexes concurrently
Hardy Ferentschik
hibernate at ferentschik.de
Fri Nov 21 09:05:53 EST 2008
On Fri, 21 Nov 2008 14:46:14 +0100, Sanne Grinovero
<sanne.grinovero at gmail.com> wrote:
>> about the size
>> =========
>> If so we need two settings I believe since the default size of these two
>> different thread pools will be different, right?
> yes you got the point, this is why I'm writing here.
> Actually the second pool size, as mentioned in other email, should be
> fixed and so we don't need to add a new parameter. This is good for the
> book ;-)
Great. If fixed size makes most sense then of course we should not add a
another
parameter.
>>> about transactions
>>> ============
> well an indexing time failure would kill a thread in the pool
> and get logged of course, but will not "kill" the committing transaction.
> This is the same semantics as of current working in async, so my guess
> is that it could stay that way at least for this release.
> Actually in sync mode the behaviour would be different.. should I catch
> the exception and pass it back to the committing thread?
> This means the exception handling is currently different in sync or
> async too, probably nobody is bothering with this detail?
Since we are keeping the worker sync/async semantic I would say that if
one of the indexing threads fails we have to propagate this back to the
caller via an Exception. In the sync mode that is. In async logging should
be
enough.
>> Will we be able to get this change in for the GA release?
>
> yes the concept code is working here, need to do some more tests
> and of course a "go" feedback from this list.
sweet.
--Hardy
More information about the hibernate-dev
mailing list