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. 

4) Geotools should be a library usable for fat clients, web container and 
ejb container. I use  geotools also  in an applet. 

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. 

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 hope my argumentation was not to extreme, but I think there are many 
developers with GIS and Java skills contributing to
a great library and we are and will kicked out of projects because some 
components are not deployable in common java environments. 

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

Reply via email to