mcr wrote: > What J2EE apps do you mean. A Web App or en EJB Container. > I mean an EJB Container; hold a geotools DefaultTransaction in your session. > J2EE Transactions are not jdbc transactions. A J2EE Transaction coordinates > many jdbc and jms resources (all resources which are able to do a 2 Phase > Commit). > Right GeoTools Transactions are not just JDBC Transaction (they are a "session" that controls many JDBC datastores and so on in one go...). They do not do a two phase commit; but that is something I would be happy to work on you with. > If you use a Container Managed Transaction the only thing you can do is > > ebjContext.setRollbackOnly() > > and thats it. And this is the job of a business logic, not geotools. > Just so; that is why we made transaction an interface; so the application could manage this stuff (tied in with their own facilities - in EJB you have a lot of nice facilities; if you need improvements to Transaction.State (ie the callback object used to hook into DataStore) please let me know. I wrote a version that did 2 phase commit - but went with the simple commit/rollback until I had a real user to drive requirements. > if you use a User Transaction (In the web Container or the EJB Container), > there is an J2EE interface. > This transaction is associated with your thread. Again, transaction > boundaries are the job of business logic and not geotools. > Got it; do you understand how to use GeoTools transaction? > The next problem you get is getting connections from a datasource. If you > call getConnection twice or more and the datasuorce provider is able to do a > 2 phase commit, nothing can happen. If your datasource provider is unable to > do a 2 phase commit, every call results in a new connection. But you cannot > ask a Connection if it is able to do a 2 phase commit. Doing commits in such > situations is the shortest way to produce trash. > Add a Transaction to your FeatureSource before use; it will only call getConnection once. We may need a connection to bootstrap (to read in the table names etc... but that should be okay should it not? It is read-only use...) > All the mapping plugins (postgis,db2,...) should obey the following rules: > > 1) Never create a connection (Jdbc, JMS,...) > That is delegated to the Transaction.State > 2) and never close one > That is delegated to the Transaction.State > 3) Needed connections are passed as a parameter from client code > We are not a raw data access api; you will need to integrate geotools into your system (ie feed us a DataSource). So you can manage the connection as part of your session; but we will want to make use of it. We may also need an additional connection to review some of the table information. > 4) Never do commit or rollback, in case of error throw an exception > That should be the case; report a problem if you find it. > 5) Never store a connection as an instance variable, the connection is only > valid for the current thread. > We only store it in a Transaction.State - ie under your control. > A plugin following these rules would be deployable anywhere. I know, this > redesign would be a challenge, but I am working with J2EE Containers since 8 > Years and these 5 points are the experience. >
> So, if you decide getting geotools ready for global Transaction Management we > will have a longer discussion, involving all the needed developers. And > believe me, all other approaches are work arounds or are usefull for special > designs, but I think we should find an universal design. > > Uppps, I hoped things become clearer, so what do you think > Sounds fine; the only hard part (ie not accounted for in the design) is you wanting to pass in a connection on a per use basis; DataStore is an abstraction so you would do better to give it a stratagy object (in this case Transaction) which it can use to integrate with your system. Doe that make sense; store a connection for us to use in your EJBSessionTransaction implementation; and call FeatureStore.setTransaction() and we should do just fine... ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
