Hi Tom,
It turns out my previous patch was way too naive. Its result is that _every_
query is run against the master. Here's why:
- the $parent_handle in mx_do_calls is either a DBD::Multiplex::db, or
a statement handle
- D::M doesn't set the AutoCommit field on itself (it passes it on to
the child dbh's)
- the result is that $parent_handle->{AutoCommit} is always false at
prepare() time, causing it to run against the mx_master
I'm currently testing the following condition instead:
(
scalar grep {
defined
&&
$_->isa('DBI::db')
&&
(! $_->{'AutoCommit'})
} @$parent_handle_list
)
I've verified that this restores the old behaviour, where selects are
performed against the first_success-ful child, and modify statements are run
against the master.
I've also tested the behaviour under transactions, and I think it is alright now.
If DBD::Multiplex would set attributes like AutoCommit on itself (in
DBD::Multiplex::db::STORE), the check could also be written as
(
$parent_handle->isa('DBI::db')
&&
!$parent_handle->{AutoCommit}
)
The grep{} looks less intrusive though.
I have attached a diff against 1.99. Feel free to undo the changes I made in
the trace_msg calls, I just needed those to see what was going on.
I have also attached a test script, including DBI_TRACE=2 output. The test
contains some private data, but I don't consider that a big problem.
The master and slave03 were hot, while slave01 was stopped expressly to show
that selects in non-transactional mode would go to slaves, while those inside
transactions would go against the master.
Note that several runs pick up the master as the first_success_random child,
which effectively defeats the purpose of replication. I'm considering using
first_success instead, putting my mx_master last. This might be something
worth mentioning in the documentation.
Oh, I would have loved to provide you with an actual unit test, but I have no
idea how to setup a replicated environment on the fly. I suppose I could come
up with something built on DBD::Mock or Test::MockDBI, but it'd probably take
quite a bit of puzzling. Let me know if you'd like to have it. I personally
very much need to know that this stuff works, so I'm willing to invest more
time and effort.
I hope the attached data provides you with enough information to see that the
current patch is actually functional.
Rhesa
Show quoted text> <URL:
http://rt.cpan.org/Ticket/Display.html?id=19266 >
>
> Rhesa,
>
> Added, as v1.99, with slightly different syntax. Please verify after the upload is processed.
>
> -- Tom
>
>
>>Hi Thomas,
>>
>>I'm using DBD::Multiplex in a MySQL replication setup. As you may know,
>>records created in a transaction aren't replicated to slaves until the
>>transaction is commited. This means that SELECTs for those records would
>>fail when issued on any slave.
>>
>>The attached patch adds a minimum amount of support for transactions.
>>The result of the new code is that transactions are run against the
>>mx_master handle only.
>>
>>I haven't made any changes to the POD, since I feel this change is too
>>small to really mention. It's merely a little more DWIM.
>>
>>Rhesa
>
>
>
>
>
