Mailing List Archive

martin f krafft wrote:
> Hi,
>
> a client of mine complains about dropped database connections
> (SybaseDA), which wreak havoc. For instance, if the network goes
> down for a while, the DA is left in an irrecoverable state.
>
> Short of a regular wget to the manage interface to restart the DA,
> what can be done? Is this something about SybaseDA (which is no
> longer maintained), or a common problem?
>
> What would you advise, short of hunting down the problem and fixing
> it?

This problem is common to all ZopeDA's connected to network data
sources. You might want to try using our mxODBCZopeDA with the option
"Connect on demand" which often helps in these situations. However, a
lot depends on how your data source and driver are configured as the
"stale" connection is often serialised even though it has been lost.

Charlie
_______________________________________________
Zope-DB mailing list
Zope-DB@zope.org
http://mail.zope.org/mailman/listinfo/zope-db

also sprach Charlie Clark <charlie@egenix.com> [2006.01.18.1451 +0100]:
> This problem is common to all ZopeDA's connected to network data
> sources. You might want to try using our mxODBCZopeDA with the option
> "Connect on demand" which often helps in these situations.

Interesting pointer, thanks a lot!

I wonder how this product determines that a stalled connection
cannot fulfill a demand.

> However, a lot depends on how your data source and driver are
> configured as the "stale" connection is often serialised even
> though it has been lost.

I am not sure what you mean with that. Most transactions are
serialised by default these days. I don't understand what that has
to do with stalled connections.

But you did write serialised *connections*. What are those?

--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck

invalid/expired pgp (sub)keys? use subkeys.pgp.net as keyserver!
spamtraps: madduck.bogus@madduck.net

*** important disclaimer:
by sending an email to any address, that will eventually cause it to
end up in my inbox without much interaction, you are agreeing that:

- i am by definition, "the intended recipient"
- all information in the email is mine to do with as i see fit and
make such financial profit, political mileage, or good joke as it
lends itself to. in particular, i may quote it on usenet.
- i may take the contents as representing the views of your company.
- this overrides any disclaimer or statement of confidentiality that
may be included on your message.

You might also consider using SQLRelay. I wrote some blog posts talking
about connecting to a relational database. There might be some useful
information there:

http://contenthere.blogspot.com/2005/12/zoracle-part-i-problem.html
http://contenthere.blogspot.com/2005/12/zoracle-part-ii-solution.html
http://contenthere.blogspot.com/2005/12/zoracle-part-iii-connecting-zope-to.html

The last of the series might be the most relevant.

--Seth

martin f krafft wrote:

>also sprach Charlie Clark <charlie@egenix.com> [2006.01.18.1451 +0100]:
>
>
>>This problem is common to all ZopeDA's connected to network data
>>sources. You might want to try using our mxODBCZopeDA with the option
>>"Connect on demand" which often helps in these situations.
>>
>>
>
>Interesting pointer, thanks a lot!
>
>I wonder how this product determines that a stalled connection
>cannot fulfill a demand.
>
>
>
>>However, a lot depends on how your data source and driver are
>>configured as the "stale" connection is often serialised even
>>though it has been lost.
>>
>>
>
>I am not sure what you mean with that. Most transactions are
>serialised by default these days. I don't understand what that has
>to do with stalled connections.
>
>But you did write serialised *connections*. What are those?
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Zope-DB mailing list
>Zope-DB@zope.org
>http://mail.zope.org/mailman/listinfo/zope-db
>
>

--
Seth Gottlieb
Optaros, Inc.
60 Canal Street
Boston, MA 02114
e: sgottlieb@optaros.com
v: 617.227.1855 ext. 107
f: 617.227.1755
m: 617.852.2956
b: http://contenthere.blogspot.com

_______________________________________________
Zope-DB mailing list
Zope-DB@zope.org
http://mail.zope.org/mailman/listinfo/zope-db

On 2006-01-18 at 15:17:24 [+0100], martin f krafft <madduck@madduck.net>
wrote:
> also sprach Charlie Clark <charlie@egenix.com> [2006.01.18.1451 +0100]:
> > This problem is common to all ZopeDA's connected to network data
> > sources. You might want to try using our mxODBCZopeDA with the option
> > "Connect on demand" which often helps in these situations.
>
> Interesting pointer, thanks a lot!
>
> I wonder how this product determines that a stalled connection
> cannot fulfill a demand.
>
> > However, a lot depends on how your data source and driver are
> > configured as the "stale" connection is often serialised even
> > though it has been lost.
>
> I am not sure what you mean with that. Most transactions are
> serialised by default these days. I don't understand what that has
> to do with stalled connections.
>
> But you did write serialised *connections*. What are those?

Running ODBC over a network involves a lot of components. Assuming there is
a network problem causing the connection to fail but the network
subsequently recovers, it is possible that the DB driver is in the same
state as the ZopeDA and does not discard the previous connection. Unless it
does this then the ZopeDA will not attempt to make a new connection. ie,
There are limits about what you can do in ZopeDA's because of Zope's
architecture.

Charlie
_______________________________________________
Zope-DB mailing list
Zope-DB@zope.org
http://mail.zope.org/mailman/listinfo/zope-db

also sprach Seth Gottlieb <sgottlieb@optaros.com> [2006.01.18.1523 +0100]:
> You might also consider using SQLRelay. I wrote some blog posts talking
> about connecting to a relational database. There might be some useful
> information there:
>
> http://contenthere.blogspot.com/2005/12/zoracle-part-i-problem.html
> http://contenthere.blogspot.com/2005/12/zoracle-part-ii-solution.html
> http://contenthere.blogspot.com/2005/12/zoracle-part-iii-connecting-zope-to.html

These are very interesting. However, with SQLRelay, I am still bound
to use SQLRelayDA for Zope, and as Charlie postulated that stale
database connections are in part due to Zope's DA framework,
I wonder how using SQLRelay would address the problem; if the
connection to the SQLRelay server is lost, Zope would similarly hang
itself up, wouldn't it?

Or do you recommend running SQLRelay on the Zope server? How does
SQLRelay then manage a connection that is stale?

Thanks,

--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck

invalid/expired pgp (sub)keys? use subkeys.pgp.net as keyserver!
spamtraps: madduck.bogus@madduck.net

"women who want to be equal to men lack ambition."
-- timothy leary

I would try having the SQLRelay listener on the Zope server and see what that
does.

--Seth

martin f krafft (madduck@madduck.net) wrote:
>
> also sprach Seth Gottlieb <sgottlieb@optaros.com> [2006.01.18.1523 +0100]:
> > You might also consider using SQLRelay. I wrote some blog posts talking
> > about connecting to a relational database. There might be some useful
> > information there:
> >
> > http://contenthere.blogspot.com/2005/12/zoracle-part-i-problem.html
> > http://contenthere.blogspot.com/2005/12/zoracle-part-ii-solution.html
> > http://contenthere.blogspot.com/2005/12/zoracle-part-iii-connecting-zope-to.html
>
> These are very interesting. However, with SQLRelay, I am still bound
> to use SQLRelayDA for Zope, and as Charlie postulated that stale
> database connections are in part due to Zope's DA framework,
> I wonder how using SQLRelay would address the problem; if the
> connection to the SQLRelay server is lost, Zope would similarly hang
> itself up, wouldn't it?
>
> Or do you recommend running SQLRelay on the Zope server? How does
> SQLRelay then manage a connection that is stale?
>
> Thanks,
>
> --
> martin; (greetings from the heart of the sun.)
> ____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
>
> invalid/expired pgp (sub)keys? use subkeys.pgp.net as keyserver!
> spamtraps: madduck.bogus@madduck.net
>
> "women who want to be equal to men lack ambition."
> -- timothy leary
>

_______________________________________________
Zope-DB mailing list
Zope-DB@zope.org
http://mail.zope.org/mailman/listinfo/zope-db

> These are very interesting. However, with SQLRelay, I am still bound
> to use SQLRelayDA for Zope, and as Charlie postulated that stale
> database connections are in part due to Zope's DA framework,
> I wonder how using SQLRelay would address the problem; if the
> connection to the SQLRelay server is lost, Zope would similarly hang

> itself up, wouldn't it?

With SQLRelay you have SQLRelay client (in this case Zope DA),
that connects to SQLRelay listener that is connected to database.
When the network connection to the database is broken then
listener becomes disconnected, but when you have some queries
from the client (Zope DA) then those reach SQLRelay listener
and become hung (in wait state) till connection becomes operational
again (im not sure but this may cause all zope threads to be busy
and Zope won't be responding). There were some questions about this
recently on sqlrelay-discussion.

-
Maciej Wisniowski
_______________________________________________
Zope-DB mailing list
Zope-DB@zope.org
http://mail.zope.org/mailman/listinfo/zope-db