The answers really helped me! Now I use “handles” and, as long as I send valid XML, the correct handle is returned to me by Geoserver.
But there is something I must be 100% sure and I’m currently not…
Jody Garnette wrote :
*> Andrea nailed it, transactions work as a single request*
Can someone confirm that it’s not possible to have this kind of process on Geoserver : begin() → send multiple requests → commit()/ rollback()
The problem is that some of our actions (insert / update / delete) depend on the execution of the previous actions. For example, let’s say we have 3 actions that must be transactional (they must all succeed or everything must be rollbacked).
action #1 is applied to Geoserver
action #2 is validated using the results of the execution of action #1. It is valid, so we apply it to GeoServer.
action #3 is validated using the results of the execution of action #2. It is NOT valid, it can’t be applied!
Here, action #3 local validation failed, so the previous actions (action #1 and action #2) must be rollbacked.
Is it possible to achieve that with Geoserver?
With a single “wfs:Transaction” request, it’s not possible to programatically validate action #3 , with local business rules, if this validation requires to check the results of the application of the previous actions.
What makes me think that it may be possible to achieve such “external” transaction controle, is that the Geotools client seems to do it. Is it?
Here, action #3 local validation failed, so the previous actions (action #1 and action #2) must be rollbacked.
You will not get back the "response" for action#3 in order to test against
your own local business rules. Any validation must occur on the server side.
Is it possible to achieve that with Geoserver?
With a single "<wfs:Transaction>" request, it's not possible to
programatically validate action #3 , with local business rules, if this
validation requires to check the results of the application of the previous
actions.
This is the case for "validating web feature service" functionality[1]
where you teach GeoServer your "local business rules so it can enforce them
during wfs:Transaction.
The code to do this is no longer hooked up (to my knowledge) as the module
lacked a chamption/funding.
It is however still in the GeoTools[2] / GeoServer codebase and if you
wire it up against we would be grateful.
What makes me think that it may be possible to achieve such "external"
transaction controle, is that the Geotools client seems to do it. Is it?
The GeoTools client holds the changes locally (as a "diff" which it uses to
filter any incoming requests), when you call commit in GeoTools it issues a
single Transaction request as described previously.
--
Jody
Sadly, GeoServer is not the place where our business logic /validation will reside. We have some web services which receive requests in a custom format, we validate them using our business logic, modify them, and some WFS requests are sent to GeoServer during this process.
So, to resume : controlling the underlying JDBC transaction used by Geoserver is not possible for a client. So no begin / commit / rollback available for the client . But it may be possible to add some validation, as plugins, on the Geoserver side.
Thanks a lot for your help Jody!
Julien
···
On 6/18/2014 7:07 PM, Jody Garnett wrote:
Here, action #3 local validation failed, so the previous actions (action #1 and action #2) must be rollbacked.
You will not get back the “response” for action#3 in order to test against your own local business rules. Any validation must occur on the server side.
Is it possible to achieve that with Geoserver?
With a single “wfs:Transaction” request, it’s not possible to programatically validate action #3 , with local business rules, if this validation requires to check the results of the application of the previous actions.
This is the case for “validating web feature service” functionality[1] where you teach GeoServer your "local business rules so it can enforce them during wfs:Transaction.
The code to do this is no longer hooked up (to my knowledge) as the module lacked a chamption/funding.
It is however still in the GeoTools[2] / GeoServer codebase and if you wire it up against we would be grateful.
What makes me think that it may be possible to achieve such “external” transaction controle, is that the Geotools client seems to do it. Is it?
The GeoTools client holds the changes locally (as a “diff” which it uses to filter any incoming requests), when you call commit in GeoTools it issues a single Transaction request as described previously.
Sadly, GeoServer is not the place where our business logic /validation will reside. We have some web services which receive requests in a custom format, we validate them using our business logic, modify them, and some WFS requests are sent to GeoServer during this process.
So, to resume : controlling the underlying JDBC transaction used by Geoserver is not possible for a client. So no begin / commit / rollback available for the client . But it may be possible to add some validation, as plugins, on the Geoserver side.
Thanks a lot for your help Jody!
Julien
On 6/18/2014 7:07 PM, Jody Garnett wrote:
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems
Here, action #3 local validation failed, so the previous actions (action #1 and action #2) must be rollbacked.
You will not get back the “response” for action#3 in order to test against your own local business rules. Any validation must occur on the server side.
Is it possible to achieve that with Geoserver?
With a single “wfs:Transaction” request, it’s not possible to programatically validate action #3 , with local business rules, if this validation requires to check the results of the application of the previous actions.
This is the case for “validating web feature service” functionality[1] where you teach GeoServer your "local business rules so it can enforce them during wfs:Transaction.
The code to do this is no longer hooked up (to my knowledge) as the module lacked a chamption/funding.
It is however still in the GeoTools[2] / GeoServer codebase and if you wire it up against we would be grateful.
What makes me think that it may be possible to achieve such “external” transaction controle, is that the Geotools client seems to do it. Is it?
The GeoTools client holds the changes locally (as a “diff” which it uses to filter any incoming requests), when you call commit in GeoTools it issues a single Transaction request as described previously.