On 09/21/2012 01:25 PM, Kim van der Riet wrote:
On Thu, 2012-09-20 at 19:47 +0100, Gordon Sim wrote:
Am I correct in my belief that there would be no benefit realised from
this work until at least one store implementation actually supports the
extra asynchronicity the new interface enables?
Correct. There is already the start of such a store (which will be an
optimized and restructured version of the existing libaio-based store),
but this will be a further block of work which can be completed for a
later release. This newer store will also be designed to allow
scalability of transactions, a limitation of the current synchronous
implementation (although not specifically related to the fact that the
interface in synchronous).
Given that fact, the potential impact and the date of completion (a week
after alpha) am I right in assuming this is targeted for merging to
trunk *after* we branch for 0.20?
It is possible that with the help of Chuck, we can run some of this work
in parallel. These timelines do not reflect this possibility, and I
still need to coordinate with Chuck on this line of work. I am hoping he
will be able to start work on part 2 above (the async/sync shim), and
his knowledge of the Windows implementation will allow him to also
address the Windows store which will also need to be wired this way.
Given there is no actual benefit until the store(s) exploit(s) the extra
asynchronicity, why would we want to get these changes in for 0.20
rather than waiting until we branch though? Seems like we would be
taking on extra risk for no benefit.
If the changes end up being low risk, are reviewed in plenty of time
before the alpha and don't cause merging issues for any actual features
(and I'm selfishly thinking AMQP 1.0 support here(!) as well as some of
the HA work), then I would be less concerned of course.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
