Christian Mueller ha scritto:
> 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.
Can you report the places where we call commits without the client
performing either a write with Transction.AUTO_COMMIT or a explicit call
to Transaction.commit?
As for the rollbacks, are you sure that's not the connection pool? DBCP
needs to cleanse out the connection before returning to the pool, so
that it's ready for a new unrelated usage, to do so it calls rollback
each time a pooled connection is closed and returned to the pool.
> 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 ?
As I said above, this is not intended, treat it as a bug and report
in jira.
> 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.
Yeah, this is problematic in some cases. For all the FeatureStore
related operations, we can just set a transaction and be done with it.
There are two problematic spots:
- using a FeatureSource directly, since it has no setTransaction method
(we should move up this method from FeatureStore... ugh, core api
change, cannot do this in 2.5.x...). Anyways, in all the cases you're
interested into right now you get back a FeatureStore
- metadata related operations, how is the datastore supposed to get a
connection there? Is it even important that it does? I mean, this
should not affect the J2EE transaction you're eventually performing.
It's nasty in that we still have to provide a datasource so that
the datastore can get its connections, for the sake of metadata
handling.
> 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.
What we need to do is to find a way for the client to build a different
kind of transaction that allows us to pass in the connection the client
first opened.
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
