From: | Chen Huajun <chenhj(at)cn(dot)fujitsu(dot)com> |
---|---|
To: | Scott Harrington <scotth01(at)sns-usa(dot)com> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: performance problem of Failover Datasource? |
Date: | 2012-12-18 00:05:54 |
Message-ID: | 50CFB362.4080701@cn.fujitsu.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Thanks for you advise.
I will try to made a new patch and add load balance supporting.
--
Best Regards,
Chen Huajun
(2012/12/16 0:19), Scott Harrington wrote:
> On Sat, 15 Dec 2012, Chen Huajun wrote:
>
>> In this patch,I use Collections.synchronizedSet to synchronize within multi-threads. But i worry about locking operation is a litter frequent by Collections.synchronizedSet and may affect
>> performance. I think using keword "synchronized" explicitly instead of Collections.synchronizedSet may reduce times of locking.Is there any better suggestion?
>>
>> In addition, I have a idea. By adjusting the order of hosts we also can implement a simple load balance while all of the hosts are master or read only slave. For example: Basically pick up the
>> server randomly.If one server had dead remove it from the candidates, and retry the next server. And after a while(can be configured) re-add the dead host to the candidates because the dead server
>> may had been repaired.
>>
>> What about that?
>
> Perhaps instead you could abstract this logic into a org.postgresql.util.HostChooser interface, which would replace the HostSpec[] array that currently gets passed around.
>
> Something like this, which doesn't require synchronization but rather stores a single volatile index of the "last known good" server address (warning: coding off the top of my head).
>
> public interface HostChooser implements Iterable<HostSpec> {
> Iterator<HostSpec> iterator();
> void reportSuccessfulConnection(HOstSpec hostSpec);
> }
>
> public class SingleHostChooser implements HostChooser
> {
> private final HostSpec hostSpec;
> public SingleHostChooser(HostSpec hostSpec) { this.hostSpec = hostSpec; }
> public Iterator<HostSpec> iterator() { return Collections.singletonList(hostSpec).iterator(); }
> public void reportSuccessfulConnection(HostSpec ignored) {}
> }
>
> public class LastKnownGoodHostChooser implements HostChooser
> {
> private final HostSpec[] hostSpecs;
> private volatile int lastKnownGood = -1;
> public LastKnownGoodHostChooser(HostSpec[] hostSpecs) { this.hostSpecs = hostSpecs.clone(); }
>
> public Iterator<HostSpec> iterator() {
> int first = lastKnownGood;
> if (first <= 0) {
> return Arrays.asList(hostSpecs).iterator();
> }
> ArrayList<HostSpec> reordered = new ArrayList<HostSpec>(hostSpecs.length);
> for (int ii = first; ii < hostSpecs.length; ++ii) {
> reordered.add(hostSpecs[ii]);
> }
> for (int ii = 0; ii < first; ++ii) {
> reordered.add(hostSpecs[ii]);
> }
> return reordered.iterator();
> }
>
> public void reportSuccessfulConnection(HostSpec hostSpec) {
> lastKnownGood = Arrays.asList(hostSpecs).indexOf(hostSpec);
> }
> }
>
>
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2012-12-18 00:20:43 | Re: JPA + enum == Exception |
Previous Message | Dave Cramer | 2012-12-17 23:18:10 | Re: JPA + enum == Exception |