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: