On Tue, Jul 17, 2018 at 12:42 AM Laurenz Albe <laurenz.a...@cybertec.at> wrote:
> Haribabu Kommi wrote: > > > On Wed, Jul 4, 2018 at 11:14 PM Laurenz Albe <laurenz.a...@cybertec.at> > wrote: > > > > Haribabu Kommi wrote: > > > > > > > > - I think the construction with "read_write_host_index" makes the > code even more > > > > complicated than it already is. > > > > > > > > What about keeping the first successful connection open and > storing it in a > > > > variable if we are in "prefer-read" mode. > > > > If we get the read-only connection we desire, close that cached > connection, > > > > otherwise use it. > > > > > > Even if we add a variable to cache the connection, I don't think the > logic of checking > > > the next host for the read-only host logic may not change, but the > extra connection > > > request to the read-write host again will be removed. > > > > I evaluated your suggestion of caching the connection and reuse it when > there is no > > read only server doesn't find, but I am thinking that it will add more > complexity and also > > the connection to the other servers delays, the cached connection may be > closed by > > the server also because of timeout. > > > > I feel the extra time during connection may be fine, if user is > preferring the prefer-read > > mode, instead of adding more complexity in handling the cached > connection? > > > > comments? > > I tested the new patch, and it works as expected. > Thanks for the confirmation. > I don't think that time-out of the cached session is a valid concern, > because that > would have to be a really short timeout. > On the other hand, establishing the connection twice (first to check if it > is read-only, > then again because no read-only connection is found) can be quite costly. > > But that is a matter of debate, as is the readability of the code. > Thanks for your opinion, let's wait for opinion from others also. I can go for the modification, if others also find it useful. Regards, Haribabu Kommi Fujitsu Australia
