Hello, Rainer Bauer wrote:
> MS> I think there are two possible ways: > > MS> 1. Spawn a separate thread in the PostgreSQL backend ... > > (You mean frontend, since the PostgreSQL backend is the server process > serving the requests) Well, no, I mean backend. This is the terminology of the SOCI project, which is composed of core and a set of backends. :-) The backend is the client-side code that is responsible for interfacing one particular DB type. > MS> ... that will consume > MS> notifications and turn them into invocations of user callbacks. > MS> Something needs to be done to avoid multithreading conflicts between > MS> that additional thread and the regular user activity, but at the end it > MS> can be done. > MS> In other words, make PostgreSQL work like Oracle. > > While this would be nice, I don't think it's SOCIs job to create > background threads. This is my worry as well. It would steer the project into areas where it does not belong. It would make more sense to offer a way for users to benefit from the threads that they can create themselves. Several other projects and APIs use this approach - there is a separate method called do_some_work() or something like this and it is supposed to be called by the user. If there is any callback generated in the background, it is being executed by the user thread and not by a thread that would need to be managed by the library itself. This is just one possibility. > MS> 2. Do not allow users to define their callbacks with the Oracle backend > MS> and instead install an internal callback that will only store the > MS> notification info and allow the user to poll and read it. > MS> In other words, make Oracle work like PostgreSQL. > > If you implement 1) users of PostgreSQL would say: > Hey cool, I don't have to care about polling and evaluating the > notification name. I only have to register a callback. Yes. > If you implement 2) users of Oracle will say: > This is much less than what I can achive using the Oracle CLI. Why > don't the SOCI designers support Oracle correctly? Right. > Let me propose a third solution: (also from Ricardo in another mail) > 3. Use polling for the PostgreSQL server and asynchronous function > calls for Oracle. Interesting, but note what are the consequences. Either there are two APIs exposed in the single class (session?) and only one of them works (kind of a design problem) or there are separate APIs exposed at the backend level. The user would obtain the backend, downcast it to the actual type and use the API that is specific to that particular backend. The Oracle backend would have API for callbacks and the PostgreSQL backend would have API for polling. Both options look a bit dodgy, but the second option has the advantage of design and implementation independence. The important question is whether the users (you!) would like to see this feature and such a design approach - fragmenting the public API space. Regards, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
