Andrea Aime wrote:
> Jody Garnett ha scritto:
>> Hi Andrea - can we get a few more details on the impact of the close 
>> method?
>>
>> - ignore: I am more used to dipose() rather than close() after some 
>> eclipse experience ;-)
>> - lifecycle: The close() needs to be stable regardless of how set up 
>> a datastore is (ie you can call it anywhere in the datastore 
>> lifecycle); you can call it more than once; it is threadsafe etc... 
>> (although the threads using the datastore may die die die) etc...
> I'd say, you can call it whenever you want, it's not guaranteed to
> be thread safe (if you still have threads working against it they
> may still work or not, this is implementation dependent).
> Making it thread safe would require keeping track of all possible
> readers/collections/sources/stores whatnot around.
> No, the moment you close it you have to assume it's screwed up.
> If the ancialliary objects keep on working good for you, but don't count
> on it :)
> How does this sound?
Cool; can we be specific that close() screws it up; but you can still 
call close() a second time.
 :-)
>> - How dows close() interact with connection pools?  Is it going to 
>> manage the internal connection pool (shut down the connections and 
>> kick out the lights?) Or if it is an external connection pool just 
>> ask postgis datastore to return any connections it was using?
> It will close only those implementing ManageableDataSource, those that
> have a close() method (DataSource has not). A datasource coming from
> JNDI won't implemement this interface.
Cool. I wanted to make sure we were not going to make code that was hard 
to port into different contexts. 
>> I have not yet been able to document your last quick proposal 
>> (introducing connection pools) :- ( Please make sure that some time 
>> is budgeted for documentation (after your release deadline if need 
>> be). I have made sure my name was not associated with your new 
>> proposal as far as documentation goes.
>
> Yeah, I took your place in that part because I need to move
> on this proposal (me making documentation, shows how desperate I am
> to get this in).
Cool; my trick is to do docs after the deadline (while I wait for bug 
reports to come in). Less stress == better docs.

Jody

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to