Some clarifications: It makes no difference if the commit/rollback call is called within the library or outside the library, that is not the problem. Sharing a common API is a good idea. The critical points are.
1) The library must not issue any commit or rollback calls for itself . This happens often when a plugin is bootstraping , reading some metadata. why issue any commit or rollbak ?. Read the meta data and the plugin is satisfied, it does not matter if the transaction is rollbacked or commited from the client code. 2) The client code is responsible for transaction boundaries. This could be done using some api from geotools, why not. How should anybody build a system with a GIS component using geotools having no control when transactions are commited/rollbacked and which transactions are used ? 3) The current design forces the plugins to open their own connections. This is a nice feature in some situations, but we have to find a possibilty to pass a connection into the plugins from the client code. Image the following the situation. 1) Client uses one database 2) Client opens a connection and executes an SQL INSERT 3) Client inserts a feature in its database using a getools jdbc plugin, using the DefaultTransaction object and registering its jdbc connection. 4) At this moment, we have 2 active connections, one from Client code, one from the plugin 5) Client issues a comit to the DefaultTransaction object, one connection succeeds, the oter fails 6) Chaos The challenge is to get this working without breaking the current code. christian On Friday 12 September 2008 18:48:58 Jody Garnett wrote: > Here is the part of the origional email where we are in agreement: > > So I would recommend: > > - Making a new Transaction interface (perhaps called Session) that meets > > your needs. This can prove the concept and serve to motivate your design > > choices. > > - Repository idea seems dead ... replace with a SessionFactory > > As for Muller's request to get transaction commit/rollback out of the > library - it will not work. We are trying to bring the various data > store implementations to an even playing field; including things like > Shapefile where there is no native concept of "transaction". > > That said we should be able to intergrate with the various systems they > propose; it will come down to how well they were designed. Some designs > focus just on JDBC and will not be suitable; others in the Java EE space > account for giving software components a chance to commit or rollback > their state and may very well be suitable. > > I look forward to reading Christian's research on the subject. > Jody > > Jody Garnett wrote: > > Andrea Aime wrote: > >> read your mail and I'm wondering if Christian really needs all of > >> what you're proposing. To "jsut" work in typical J2EE enviroment > >> where you only have databases around, no files, no remote servers, > >> I believe there would be no need for a repository concept, but > >> just a Transaction class that can participate in the declarative > >> transaction set up. > > > > Indeed that is what I recommend at the end of the email - the production > > of a SessionFactory that can be provided by GeoServer; (where Session > > > Transaction ). > > > > Cheers, > > Jody > > > > ------------------------------------------------------------------------- > > 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 > > ------------------------------------------------------------------------- > 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 ------------------------------------------------------------------------- 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
