Hi 2009/8/14 Maciej Sobczak <[email protected]>: > Hello, > > Rainer Bauer wrote: > >> In short: asynchronous notifications. >> >> Long story: If you have multiple programs accessing/updating the same >> data and you have to ensure that the displayed (i.e. locally cached) >> data is always up-to-date you have two options: >> 1) Issue SELECT statements in specific intervals to determine whether >> the cached data is still up-to-date. >> 2) Use triggers and notifications. In this case the application only >> has to check whether event was notified and can then synchronize the >> cached data. > > Yes, this is a good use-case. We are using something much more elaborate > with Oracle, but there it involves message queues based on JMS and all > kind of machinery that is not even related to direct client-server > interactions. > > I have investigated the PostgreSQL support for notifications and what > bothers me is that the notification queue needs to be periodically > polled in order to discover new events and even this can only report on > events that were received from server as a result of other client's > activity. This means that the client program has to do *something* > regularly (even sending empty commands to the server) in order to have > these notifications delivered. > According to PostgreSQL docs, more recommended solution is to obtain the > socket descriptor that belongs to the client's connection and select() > on it until it is ready for reading. This should allow the client to > block instead of polling periodically. > In any case, the notifications are delivered through a single channel > and the user is responsible for dispatching them on his own, if there > are many registered notifications with different names. > Yes, it can be done. > > The biggest problem that I see is that this model is different from what > is available in Oracle. There, the client application can subscribe for > notifications that are either related to particular objects (like > tables) or to the given query results, with possibly different callbacks > for each subscription. Then, whenever a given database object is > modified (or a query could provide different results), the call is made > into the user code. > > In other words: > 1. PostgreSQL uses active polling (client has to check if there is > something new) on the "notification" object which is visible at the > server and is acted upon by other clients, > 2. Oracle uses passive callbacks (client code is being invoked > automatically) and no special server-side objects. > > I do not even dream of a portable meachanism here, which would magically > hide these differences and allow the user to write a single program that > would work without changes with both servers. :-) > We do not promise SQL-level portability anyway, so this is not the goal > here. > > But I would like to imagine at least a consistent API at the SOCI level. > Any suggestions are highly welcome. > > I think there are two possible ways: > > 1. Spawn a separate thread in the PostgreSQL backend that will consume > notifications and turn them into invocations of user callbacks. > Something needs to be done to avoid multithreading conflicts between > that additional thread and the regular user activity, but at the end it > can be done. > In other words, make PostgreSQL work like Oracle. > > 2. Do not allow users to define their callbacks with the Oracle backend > and instead install an internal callback that will only store the > notification info and allow the user to poll and read it. > In other words, make Oracle work like PostgreSQL. > > The second option is simpler to implement and can be sufficient in the > context of SOCI. > > Please do not hesitate to share your thoughts on this.
First of all, this is my first mail on the list, so thanks for this great library ;) Regardless of implementation complexity, from my point of view as developer and soci api user i prefer the first option because i think that it more flexible than the second. You can always "emulate" the polling behaviour if the user want it building a layer on top of soci. On the other hand with the second approach it seems more difficult to develop an asynchronous layer based on the second option if the user wants it. But to gild to lily offer the two options will be killer ;) If the user define a callback invoque it, if not let the user poll and read. But i dont know if its feasible. I hope that I explain correctly, regards. -- Ricardo Muñoz Fernández Warp Networks S.L. - http://www.warp.es ------------------------------------------------------------------------------ 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
