Re: Lost connection after postgres restarted - Mailing list pgsql-jdbc

From John Sidney-Woollett
Subject Re: Lost connection after postgres restarted
Date
Msg-id 4525.192.168.0.64.1074780705.squirrel@mercury.wardbrook.com
Whole thread Raw
In response to Re: Lost connection after postgres restarted  (Nicolas Modrzyk <Nicolas.Modrzyk@inrialpes.fr>)
List pgsql-jdbc
Hi Nicolas

We use functions a lot to abstract business logic away from our java
middle tier. We would want the stored procedures to be called in all
databases, because if this didn't happen then the databases would become
inconsistant, and we would be better off using a different replication
method.

We also use updateable resultsets which are also not supported.

I can see though that if you're just reading and writing to the DB
(cluster), that C-JDBC would be superb!

I understand your difficulty and am not sure of the best means of either
detecting a failing or failed server in the cluster, or distinguishing
between a good reply or a bad reply from all the dbs in the cluster when
there are differences.

Perhaps the C-JDBC driver can detect any difference in function results
(or out parameters (but not for postgres!)), and then throw an exception.
But what the java app does with that exception I don't know, because the
call may have legitimately worked on one of the servers...

Perhaps some other developers can give some comments, ideas or feedback.

John

 Nicolas Modrzyk said:
> Hi John,
>
> C-JDBC does support simple stored procedures calls, but we are
> wondering about control of these calls...
>
> For example, in a heterogeneous cluster of database, do you want to
> force each database to implement all of the functions ?
> If a call to a store procedure fails, how do you detect it ?
> If a call get multiple different return values or out parameters, how
> to you react ?
> Which return value do you keep ? How do you verify synchronization of
> the different backends of the cluster ?
>
> I'd be interest in putting those features in C-JDBC for a cluster of
> postgresql backends since they have de facto large support for store
> procedures.
>
> For homogenous clusters, this is a short term plan, so maybe we can
> work something together with your solution ?
>
> Nicolas Modrzyk.
>
> On Thursday, January 22, 2004, at 10:41 AM, John Sidney-Woollett wrote:
>
>> C-JDBC is a really interesting idea! I have has a look at it in the
>> past,
>> and stopped when I discovered that the cluster cannot support functions
>> that return results eg
>>
>> {? = call <procedure-name>[<arg1>,<arg2>, ...]}
>>
>> Is this restriction still in place? We use functions a lot, and it is a
>> show stopper for us.
>>
>> In fact, it is what is driving us to use an alternate replication
>> system,
>> since we want our db replicated.
>>
>> Thanks for any info.
>>
>> John Sidney-Woollett
>>
>> Nicolas Modrzyk said:
>>> Hi,
>>>
>>> Since we're implementing transparent connection pooling in C-JDBC, you
>>> can run C-JDBC on top of the Postgresql driver
>>> and you'll be able to recover your connection without starting
>>> stopping
>>> application.
>>> And since, C-JDBC is basically a cluster, you can replicate your
>>> Postgresql database on multiple backends, and when the
>>> time of backing up has come, only one of your database backend will be
>>> offline during the process, the other ones will still be available.
>>>
>>> Maybe you should have a look ...
>>>
>>>
>>> Nicolas,
>>>
>>>
>>> ---
>>> Nicolas Modrzyk
>>> Software Engineer INRIA Rhone-Alpes
>>> C-JDBC http://c-jdbc.objectweb.org
>>>
>>
>>
>>
>
>


pgsql-jdbc by date:

Previous
From: Nicolas Modrzyk
Date:
Subject: Re: Lost connection after postgres restarted
Next
From: Kris Jurka
Date:
Subject: Using gettext for JDBC translations