High Andrea, 1) There was a misunderstanding, I wrote
"3) UDIG and Geoserver are no references because (as far as i know) they do not use NON geotools transactional resources" meaning that these 2 products are doing all their transaction handling with geotools having no further transactional resources with direct connections. I am talking about using geotools in other environments, it is obvious that udig, geoserver and geotools fit together. 2) What is a transaction on a shape file ?. Does this make sense ?. I think the only reason for this is to have a common API. For WFS, ArsSde,... it make sense, of course. To do a step forward I did some investigations of the Transaction API and got the following ieda according to your proposal: Create a new Class class J2EETransaction implements Transaction ... making 2 Constructors // case a) for use in a servlet enginge, obtaining a user Transaction from JNDI public J2EETranscation(String jndiName) // case b) obtaining a user managed Transaction with ctx.getUserTransaction and calling th begin() Method // case c) do nothing for a container managed Transaction public J2EETransaction(EJBContext ctx, boolean usermanaged) Now we can implement the commit and rollback methods for a) and b) using the begin(),commit() and roolback() methods of the J2EE User Transaction object, for c) we do nothing. The problem is the putState(..) method. A container allows one global Transaction composed of a set of XA resources and many stand alone connections (each connection has its own transaction handling). The handling of the stand alone connections is already implemented registering a JDBCConnectionState using the putState method. See JDBC1DataStore>>getConnection(Transaction t). For connections participating in the global transaction the putState method should do nothing. (Ignoring the state to avoiding commits and rollbacks). But you cannot ask a connection if it is registered in the global Transaction, so i have no idea to implement the putState() Method registering stand alone connections and not registering the others. A possibility would be to have a DefaultTransaction object for all standalone Connections and one J2EETransaction object for all XA connections. Not the best design but it could work and if we document it, why not. And we would break no code. What do you think ? christian ------------------------------------------------------------------------- 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
