First, thanks all for the feedback and good luck with the new
release!
>
> > A possible approach is for your clients to maintain more than one
> > backend connection, and use one of the backends to do the stuff
> > that might block while using another one to do the stuff that won't.
Yes. Same effect as PQreset() if the code is to be ran only once, but
a lot better if inside a loop!.
> Or you could do it outside of the database using a Unix filesystem lock
> file. There are symantics for no-blocking lock stuff in flock():
>
> #define LOCK_SH 0x01 /* shared file lock */
> #define LOCK_EX 0x02 /* exclusive file lock */
> #define LOCK_NB 0x04 /* don't block when locking */
> #define LOCK_UN 0x08 /* unlock file */
Exactly what's wanted in this case. The unix flock() locks a file or,
if already locked, either waits or fails depending on what you
requested. The lock is released by either an unlock operation or the
death of the locking process. It would solve my problem, except it
requires all clients to share a filesystem.
> I don't know of any SQL databases that allow non-blocking lock requests.
I'm not very familiar with full-scale SQL but seems odd not to have
such things. I guess from the language point of view there ought to be
a way to know when an item is unavailable/undefined (it's been locked
for writing), if you don't want to wait a long time to get a value.
Imagine I go to the store at 11am and can't buy soap - because
the price of soap is unknown because it's a heavy trading day for soap
at the ny stock exchange. Even if the shop's definition may not allow for
soap to be sold before the stock market closes and the final price is
known, I shouldn't be forced to wait there doing nothing. I can do
other shopping around and come back later for my soap! ;-)
Regards,
Pablo
