Re: [HACKERS] ObjectWeb/Clustered JDBC

2003-11-28 Thread Hans-Jrgen Schnig
Peter Eisentraut wrote:
Hans-Jürgen Schönig writes:


Especially the disaster recovery mechanism and things such as adding new
masters need some more work.


Yes, someone is working on automatic recovery (which would extend to
adding new masters by starting recovery from zero).  In fact, they're just
across town from you (together.at).


Guess who has taught them PostgreSQL ;).

	Hans

--
Cybertec Geschwinde u Schoenig
Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
Tel: +43/2952/30706 or +43/660/816 40 77
www.cybertec.at, www.postgresql.at, kernel.cybertec.at


---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [HACKERS] ObjectWeb/Clustered JDBC

2003-11-28 Thread Hans-Jürgen Schönig
Dave,

I know that the backend does - it is an essential feature.
Clustered JDBC parses the statement sent to it in order to find out what 
to do with it. I have played around a little (mostly interactive shell). 
You will find out that Clustered JDBC will complain in this case because 
it doesn't know what to do with it. If you are a tool support load 
balancing and this kind of stuff DECLARE CURSOR can be painful to 
implement - especially across multiple transactions.
Is is a very weak point of the current beta version.

	Regards,

		Hans

Dave Cramer wrote:
Hans,

I don't understand the statement about missing DECLARE CURSOR ? The
backend supports it?
Dave
On Sun, 2003-11-23 at 12:12, Hans-Jürgen Schönig wrote:
Peter Eisentraut wrote:

I was at the ObjectWeb Conference today; ObjectWeb
(http://www.objectweb.org) being a consortium that has amassed quite an
impressive array of open-source, Java-based middleware under their
umbrella, including for instance our old friend Enhydra.  And they
regularly kept mentioning PostgreSQL in their presentations.
To those that are interested in distributed transactions/two-phase commit,
I recommend taking a look at Clustered JDBC
(http://c-jdbc.objectweb.org/).  While this is not exactly the same thing,
it looks to be a pretty neat solution for a similar class of applications.
In particular, it provides redundancy, load balancing, caching, and even
database independence.


It is indeed a nice solution but it is far from ready yet.
Especially the disaster recovery mechanism and things such as adding new 
masters need some more work.
What I really miss is DECLARE CURSOR. Maybe it will be in there some 
day :).
However, we have done some real testing with sync replication (4 x pg, 1 
x oracle). It performed surprisingly well (the JDBC part, not the Oracle 
one ;) ).
Maybe this will be something really useful within the next few months.

	Cheers,

		Hans




--
Cybertec Geschwinde u Schoenig
Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
Tel: +43/2952/30706 or +43/660/816 40 77
www.cybertec.at, www.postgresql.at, kernel.cybertec.at


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
 subscribe-nomail command to [EMAIL PROTECTED] so that your
 message can get through to the mailing list cleanly


Re: [HACKERS] ObjectWeb/Clustered JDBC

2003-11-25 Thread Dave Cramer
Hans,

I don't understand the statement about missing DECLARE CURSOR ? The
backend supports it?

Dave
On Sun, 2003-11-23 at 12:12, Hans-Jürgen Schönig wrote:
 Peter Eisentraut wrote:
  I was at the ObjectWeb Conference today; ObjectWeb
  (http://www.objectweb.org) being a consortium that has amassed quite an
  impressive array of open-source, Java-based middleware under their
  umbrella, including for instance our old friend Enhydra.  And they
  regularly kept mentioning PostgreSQL in their presentations.
  
  To those that are interested in distributed transactions/two-phase commit,
  I recommend taking a look at Clustered JDBC
  (http://c-jdbc.objectweb.org/).  While this is not exactly the same thing,
  it looks to be a pretty neat solution for a similar class of applications.
  In particular, it provides redundancy, load balancing, caching, and even
  database independence.
  
 
 
 It is indeed a nice solution but it is far from ready yet.
 Especially the disaster recovery mechanism and things such as adding new 
 masters need some more work.
 What I really miss is DECLARE CURSOR. Maybe it will be in there some 
 day :).
 However, we have done some real testing with sync replication (4 x pg, 1 
 x oracle). It performed surprisingly well (the JDBC part, not the Oracle 
 one ;) ).
 Maybe this will be something really useful within the next few months.
 
   Cheers,
 
   Hans


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [HACKERS] ObjectWeb/Clustered JDBC

2003-11-25 Thread Peter Eisentraut
Hans-Jürgen Schönig writes:

 Especially the disaster recovery mechanism and things such as adding new
 masters need some more work.

Yes, someone is working on automatic recovery (which would extend to
adding new masters by starting recovery from zero).  In fact, they're just
across town from you (together.at).

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


[HACKERS] ObjectWeb/Clustered JDBC

2003-11-21 Thread Peter Eisentraut
I was at the ObjectWeb Conference today; ObjectWeb
(http://www.objectweb.org) being a consortium that has amassed quite an
impressive array of open-source, Java-based middleware under their
umbrella, including for instance our old friend Enhydra.  And they
regularly kept mentioning PostgreSQL in their presentations.

To those that are interested in distributed transactions/two-phase commit,
I recommend taking a look at Clustered JDBC
(http://c-jdbc.objectweb.org/).  While this is not exactly the same thing,
it looks to be a pretty neat solution for a similar class of applications.
In particular, it provides redundancy, load balancing, caching, and even
database independence.

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html