Hello Maciej, Friday, August 14, 2009, 10:52:57 AM, you wrote:
MS> I have investigated the PostgreSQL support for notifications and what MS> bothers me is that the notification queue needs to be periodically MS> polled in order to discover new events and even this can only report on MS> events that were received from server as a result of other client's MS> activity. This means that the client program has to do *something* MS> regularly (even sending empty commands to the server) in order to have MS> these notifications delivered. Correct. You have to call PQconsumeInput() on the client side. MS> According to PostgreSQL docs, more recommended solution is to obtain the MS> socket descriptor that belongs to the client's connection and select() MS> on it until it is ready for reading. This should allow the client to MS> block instead of polling periodically. This would be only acceptable if a separate worker thread is used. MS> In any case, the notifications are delivered through a single channel MS> and the user is responsible for dispatching them on his own, if there MS> are many registered notifications with different names. MS> Yes, it can be done. Exactly. MS> The biggest problem that I see is that this model is different from what MS> is available in Oracle. There, the client application can subscribe for MS> notifications that are either related to particular objects (like MS> tables) or to the given query results, with possibly different callbacks MS> for each subscription. Then, whenever a given database object is MS> modified (or a query could provide different results), the call is made MS> into the user code. I googled around a bit since I'm not familiar with Oracle: <http://download.oracle.com/docs/cd/B14117_01/appdev.101/b10779/oci09adv.htm#462246> describes the callback signature and <http://download.oracle.com/docs/cd/B14117_01/appdev.101/b10779/oci09adv.htm#471828> gives an example. The notifications in PostgreSQL are either generated by other clients or by the backend using triggers (which is much more convenient). But compared to Oracle the notifications are much more limited. MS> In other words: MS> 1. PostgreSQL uses active polling (client has to check if there is MS> something new) on the "notification" object which is visible at the MS> server and is acted upon by other clients, MS> 2. Oracle uses passive callbacks (client code is being invoked MS> automatically) and no special server-side objects. MS> I do not even dream of a portable meachanism here, which would magically MS> hide these differences and allow the user to write a single program that MS> would work without changes with both servers. :-) MS> We do not promise SQL-level portability anyway, so this is not the goal MS> here. Glad to hear this. MS> But I would like to imagine at least a consistent API at the SOCI level. MS> Any suggestions are highly welcome. 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) 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. You would have to introduce a threading library (or create your own layer) supporting all SOCI platforms. 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. 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? Let me propose a third solution: 3. Use polling for the PostgreSQL server and asynchronous function calls for Oracle. Let's face it, people using notification functions won't be writing software that must be portable between DBMS. Most likely they use SOCI as an easy and fast access method to their choosen database. If someone wants to use notifications with PostgreSQL AND Oracle he will have to build his own abstraction layer on top of SOCI. Then it's their decision to implement your proposed solution 1) or 2). Rainer ------------------------------------------------------------------------------ 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
