gnustep/libs-sqlclient
0
0
Fork 0
mirror of https://github.com/gnustep/libs-sqlclient.git synced 2025-02-19 10:00:59 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Don't allow pool clients to be set as database notification observers

Browse source 
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/sqlclient/trunk@40152 72102866-910b-0410-8b05-ffd578937521
This commit is contained in:
rfm 2016-10-18 08:32:05 +00:00
parent dd330e58b8
commit f519b6df21
3 changed files with 34 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
ChangeLog
View file

@ -1,3 +1,11 @@
2016-10-18 Richard Frith-Macdonald <rfm@gnu.org>
* SQLClient.h:
* SQLClient.m:
Make -addObserver:selector:name: raise if applied to a client in a
pool. Improve documentation to make it clear that pool clients
can't be used as observers of database notifications.
2016-06-23 Richard Frith-Macdonald <rfm@gnu.org>
* SQLClient.m: Fixup to use case sensitive notification names.

22
SQLClient.h
View file

@ -1291,7 +1291,13 @@ SQLCLIENT_PRIVATE
* occur inside a transaction is the -begin and -commit statements
* are used. For this reason, observing code may want to use the
* -lockBeforeDate: -isInTransaction and -unlock methods to ensure
* that they don't interfere with ongoing transactions.
* that they don't interfere with ongoing transactions.<br />
* For observation of notifications to be immediately effective, the
* instance must be connected to the database (and remain connected),
* so you can't call this method on a client from a pool, and you should
* make sure that you don't close the client connection (or if you do,
* that you make sure to re-open it in order to start receiving
* notifications again).
*/
- (void) addObserver: (id)anObserver
selector: (SEL)aSelector
@ -1578,6 +1584,13 @@ typedef struct {
* method which would be required to be followed up by another message to
* the same client.
* </p>
* <p>NB. Any client provided from a pool should be returned to the
* pool as soon as reasonably possible (and if left idle will have its
* connection to the server closed anyway) so that it can be used by
* other threads. If you want a permenantly open database connection
* you should use a normal SQLClient instance, not one from a pool.
* You must not call -addObserver:selector:name: on a client from a pool.
* </p>
*/
@interface SQLClientPool : NSObject
{
@ -1669,7 +1682,12 @@ typedef struct {
* If isLocal is YES, this method provides a client which will not be
* used elsewhere in the same thread until/unless the calling code
* returns it to the pool. Otherwise (isLocal is NO), the client may
* be used by other code in the same thread.
* be used by other code in the same thread.<br />
* NB. Any client provided using this method should be returned to the
* pool as soon as reasonably possible (and if left idle will have its
* connection to the server closed anyway) so that it can be used by
* other threads. If you want a permenantly open database connection
* you should use a normal SQLClient instance, not one from a pool.
*/
- (SQLClient*) provideClientBeforeDate: (NSDate*)when exclusive: (BOOL)isLocal;

7
SQLClient.m
View file

@ -3054,7 +3054,7 @@ static int poolConnections = 0;
}
else
{
/* Not really an asynchronous query becuse we wait until it's
/* Not really an asynchronous query because we wait until it's
* done in order to have a result we can return.
*/
[self performSelectorOnMainThread: @selector(_populateCache:)
@ -3867,6 +3867,11 @@ validName(NSString *name)
[NSException raise: NSInvalidArgumentException
format: @"Attempt to add nil observer to SQL client"];
}
if (nil != _pool)
{
[NSException raise: NSInvalidArgumentException
format: @"Attempt to use pool client as observer"];
}
name = validName(name);
[lock lock];
NS_DURING