Re: DCE RPC to Oracle 7 database

Peter Sylvester wrote: > > In article <311855DF.41C6@steffl.aui.dec.com>, Andreas Reichenberger > <reichenb@steffl.aui.dec.com> wrote: > > > Richard Moulding wrote: > > > > > > I need to interface to an Oracle 7 DB from DCE (non-Oracle) > > > clients. We are planning to build our own DCE RPC-stored > > > procedure interface but someone must be selling something to do > > > this, no? > > I have the same problem with an Informix application which uses a DCE > interface, and currently limit it to 1 thread coming in. This works, but > could be a bottleneck in busy environments, as other incoming RPCs are put > in a queue (blocked) until the current one finishes. ... stuff deleted > A potential way around this would be to fork off separate processes which > then start their own connection to the database. The parent then acts as a > dispatcher for requests coming in. I know the forking part works without > DCE, but I suspect that you have to do all the forks before going into the > DCE server listening mode. > > I also thought I heard something about Oracle providing a thread safe > library, maybe in 7.3. Anyone know? > > -- > Peter Sylvester > MITRE Corp. > Bedford, MA > (peters@mitre.org) This is exactly the way we handled the problem. We wrote a tool that generates the complete dispatcher from an IDL file. The dispatcher (which is virtually invisible to the clients and to the developers) distributes the requests from the clients to its 'backends', which are connected to the DB. The backends are implemented as single-threaded DCE Servers with the Interface specified in the IDL File. We added some features that are not in DCE, like - asyncronous RPC's (the RPC returns immediately and the client can ask the dispatcher to return the state of the RPC (if it is done or still running) or request the RPC to be canceled) - dividing the backends into classes. i.e. it's possible to have one class of backends for querying the database and another class for updates, etc. By assigning 2 backends to the query class and the rest of the backends to other classes you can limit the number of concurrent queries to 2 (because they are time consuming). The client has to specify which class is to be used for a RPC (we currently support up to 10 classes) Context handles are used to tie a client to one backend for transactions which require more than one RPC to be handled by the same backend (= DB Session). The reason why the hell we had to do this anyway was to limit the number of backend processes neccessary to support a few hundred PC clients. We currently run it on AIX and Digital UNIX with Oracle and Ingres. However, there's no reason why it shouldn't work on any UNIX platform which supports OSF DCE (V1.1) and with any DB. Feel free to contact me for more details... See 'ya