<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<style>body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;"
bidimailui-detected-decoding-type="latin-charset" bgcolor="#ffffff"
text="#000000">
On 08/18/2011 07:57 AM, Chris Travers wrote:
<blockquote
cite="mid:CAKt_Zfs7392g+xyS-6_RBkFsmmUooftL=SZOefONH9=d8Ef+BA(at)mail(dot)gmail(dot)com"
type="cite">
<pre wrap="">On Wed, Aug 17, 2011 at 9:38 PM, Sim Zacks <a class="moz-txt-link-rfc2396E" href="mailto:sim(at)compulab(dot)co(dot)il"><sim(at)compulab(dot)co(dot)il></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">The point was not whether I have a bug in an external application, the point
is that I need an external application which creates more overhead and
another point of failure in the application stack.
</pre>
</blockquote>
<pre wrap="">1) Not sure how an external python script is different from a
PL/Python sproc except that the former exists external to transaction
control.
</pre>
</blockquote>
There are many differences. <br>
1) If I have a database function and I copy my database to another
server, the function still works. <br>
If I have an external daemon application, I not only have to copy my
database, I also have to copy the daemon application. Then I have to
build an init script and make sure it runs at startup. My
LISTEN/NOTIFY daemon is a c application, so when I move my database
to a server on a different platform, I have to recompile it. <br>
<blockquote
cite="mid:CAKt_Zfs7392g+xyS-6_RBkFsmmUooftL=SZOefONH9=d8Ef+BA(at)mail(dot)gmail(dot)com"
type="cite">
<pre wrap="">2) there is absolutely no reason you can't build redundancy into this system.
</pre>
</blockquote>
Its not a question of whether I can or cannot build redundancy, it
is a question of whether I have to build an entire system in order
to call a database function from another database function. The only
reason this is complicated is because it needs to be in its own
session. That simple issue shouldn't force me to build: a) a daemon
application, b) include redundancy to ensure that it is running, c)
not be included in my database backup/restore.<br>
Remember, I don't want to build a _system_, I basically want an
asynchronous trigger. On specific event call a database function in
its own transaction space and allow the existing transaction to end.
<br>
<blockquote
cite="mid:CAKt_Zfs7392g+xyS-6_RBkFsmmUooftL=SZOefONH9=d8Ef+BA(at)mail(dot)gmail(dot)com"
type="cite">
<pre wrap="">3) The overhead really shouldn't be bad, and if your parts are
well-modularized, and carefully designed overhead really should be
minimal.
</pre>
</blockquote>
Any overhead that is not necessary should not be added in. It is the
minor level of frustration that something didn't work when I
migrated servers until the "Oh Yeah" kicked in. Then looking through
all my notes to find the compilation instructions for my daemon
because we moved from a 32 bit server to a 64 bit. Then trying to
figure out the syntax for the init script, because we moved from
Gentoo to Debian and it is slightly different. It isn't a lot of
overhead but it is completely unneccessary in our situation. <br>
I will agree that this is entirely necessary if your application
actually uses an external system and the database communicates
through Listen/Notify. You have 2 systems to deal with in any case,
but for me the only external component is having the daemon listen
so it can call another function in the database. IOW, I don't
generally deal with anything else on the server.<br>
<br>
<blockquote
cite="mid:CAKt_Zfs7392g+xyS-6_RBkFsmmUooftL=SZOefONH9=d8Ef+BA(at)mail(dot)gmail(dot)com"
type="cite">
<pre wrap="">Best Wishes,
Chris Travers
</pre>
</blockquote>
<p>Sim<br>
</p>
</body>
</html>