Christian Müller ha scritto: > > 1) I think I should make a proposal in the wiki (where is the best place)
> 2) I am working on a system handling animal deseases. A typical transaction > does modifications on an host db2, stores zone geometries in an AIX DB2 > and puts > some informations for animal doctors in a jms queue (resulting in emails > later on, the email sending is not part of the transaction). > All or nothing,otherwise we would have chaos. > I tried to use geotools and failed because the db2-plugins makes commits > which is not allowed in a global Transaction. > 3) UDIG and Geoserver are no references because (as far as i know) they > do not use non geotools transactional resources. What do you mean? GeoServer WFS Transaction code uses GeoTools Transactions. > 4) Geotools should be a library usable for fat clients, web container > and ejb container. I use geotools also in an applet. Indeed. But GeoTools can go only where developers drive it, and that depends on what developers do need or are paid to develop. So if you need EJB compatibility, you have to be the one pushing for it. > 5) It makes no sense to devolop some abstraction for transaction > handling because within the geotools code you never > can decide about transaction boundaries (which is easy to show with some > scenarios). Transaction handling is part of the client code and/or the > J2EE middleware, we should not worry about that, that is not our job. > And we should not investigate to produce > code if we can agree (and I hope so) that we will never succeed. A datastore is not necessarily a database. How does client code handle transactions against shapefiles? How does client code perform a transaction against a remote WFS server? And moreover, how do allow wrinting code that does transactions without knowing the nature of the underlying datastore? (the very reason we have the DataStore family of interfaces). > 6) My solution for all geotools components using transactional > resources (JDBC Connection, JMS Connection, JCA Adapters) would be > 1) no commit and no rollback calls. > 2) no getConnection and no Connection>>close > The client code is resposible for 1) and 2), the only thing we have to > do is a redesign that the client is able > to pass a connection object as a parameter where we need it. > This proposal would solve 4), we could remove all the code handling > transactions and can focus on the mapping job. > Btw, at the moment we have a redesign in the h2 module, this is good > point in time if we get some consensus. I disagree on your point of view. Please explain how do I make code that does transactions the same ways against a dbms, a remote wfs service, a shapefile. What you need are hooks for the case in which you are using just databases and in a ejb container. It's a special case, nor uDig nor GeoServer have such a narrow set of use cases. I believe my suggestion in the previous mail still stands, it does not break existing clients, and allows people to build their own custom code relying on the ejb container. Cheers Andrea ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
