[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: notification of connection closure to database backends.



Kurt D. Zeilenga wrote:

> At 06:07 PM 6/22/99 +0200, Bastiaan Bakker wrote:
> >Hi,
> >
> >While working on the CORBA database backend I noticed that there's no
> >way for a backend to receive a notification of the closing of a client
> >connection. In most cases this is not a problem, but the CORBA backend
> >needs to maintain state on a per connection basis. If it doesn't know
> >when a connection closes, it cannot release its state nor notify the
> >backend server to release any resources (both CPU and memory) in use for
> >that connection.
> >The way I would like to add notification support is to include a NULL
> >terminated list notification callback functions in each connection
> >structure. Each backend interested in the destruction of the connection
> >can add its own callback function to this list. The
> >'connection_destroy()' operation shall call each of the functions in the
> >list with a pointer to the connection as argument.
> >The overhead of this feature is small: addition of a void** member to
> >the ldap_conn struct and an 'if !=NULL call all in the list' in the
> >'connection_destroy()' method.
> >If anyone has objections to this approach or knows a better way to do
> >the same, please let me know or I'll start coding.
>
> I think I'd rather extend the existing backend interface to support
> this...
>
> I suggest adding two additional functions that can be registered
> by backend ends:
>         (be->be_connection_init)(conn) and
>         (be->be_connection_destroy)().
>
> connection_init(fd), AFTER intializing the connection, would call
> be_connection_init(conn) which in turn would call the provided
> be->be_connection_init(conn) routines.
>
> connection_destroy(), BEFORE destorying the connection, would call
> be_connection_destory(conn) which in turn would call the provided
> be->be_destory_init(conn) routines.
>
>         Kurt

Wouldn't this imply that only one backend can have state associated with a
particular connection? I thought it was allowed to bind with one backend and
search, etc. with another?
If I'm wrong I'll be happy to adopt your approach because I don't find mine
very elegant.

Bastiaan

begin:          vcard
fn:             Bastiaan Bakker
n:              Bakker;Bastiaan
org:            LifeLine Networks BV
email;internet: Bastiaan.Bakker@lifeline.nl
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard