Ben Caradoc-Davies ha scritto: > +1 for me. > > This could be quite useful for app-schema deployments, because > app-schema is a database connection hog (and uses multiple connections > to service a single request [naughty, naughty]), so control flow could > be used to limit the number of requests to avoid connection pool > deadlock in production deployments. Niiice.
Connection pool deadlocks? Those are normally a problem with application design... let me think about it... you are merging multiple data streams coming from the same database, and each is using a separate connection, and that can definitely cause deadlocks (I experienced those last year during the WMS shootout because the Oracle data store needed, on occasion, a second connection, and boom, server deadlock on higher loads). Wondering if you can open a Transaction, set it into the feature sources, so that all of them operating against the same db will share a single connection. That would improve the scalability significantly.... Hmm... that's something you can pull off only if you're playing against stores, pity, that is a significant shortcoming of the current datastore api imho, also FeatureSource should have a setTransaction method (for other good reason past the connection sharing). For the time being you can still try to set the same transaction against all the feture sources that happen to be stores at the same time ;-) Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
