Jody Garnett ha scritto: > Andrea Aime wrote: >> Ah ha, interesting one. > That is always a scary statement comming from you Andrea. It usually > means I have uncovered something that is going to hurt my brain to > figure out. >> LRU already has its own priority (you get to top when used and move >> towards the land of the dead when others are >> used), wouldn't adding another priority concept mess up things? >> What about having multiple queue, and a way to set a "regionId" or >> something like that to decide in which queue a resource ends up? >> Most datastores may end up in the standard ds queue, but some, >> like ArcSDE, and maybe WFS and Oracle (when not using JNDI pools) >> should end up in their own? > Okay lets me try getting out of this quick: > - do *nothing* for the first cut; LRU is simple and we got enough going > on (I think everyone is tired right now and we need to rest up before > the sprint; draw some icons or something) > - do *nothing* for the second cut; and punt the responsibility on your > "DataSource" factory finder should take care of recycling JDBC "pools" > should it not?
No, it should not, seems like a scary mistake instead. If the factories keep the pools around, how do you get rid of them? Would you be happy if a misconfigured arcsde pool that you already dropped kept on eating your preciously payed client licenses? Such resource management should not be mandated to the factory finder in my opinion, but to the user code, that knows the specific use case you're dealing with. > The only thing that leaves out in the cold is ArcSDE; a concern for a > small portion of our users so ... > - consider a "priority" or a flag to keep something like an ArcSDE entry > in the queue when an arcsde user notices and asks us for it I still feel a pool managed by geoserver with multiple regions is a better solution. That ensures SDE gets its own queue, so that nobody will kick it out of it, and allows GeoServer to get rid of the connection and its pool when the user removes the datastore. Cheers Andrea ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
