Hey all,
I'm in the process of avoiding GWC to whip out the whole layer cache upon every transaction.
To that end, I need to make good use of transaction events, but to make _good_ use of them I'd need two things:
- first, currently only update transactions issue post events. Insert, update and delete issue pre events.
- second, it'd be great that post events were always thrown. I think the rationale behind not issuing post events for insert and delete is that the affected features won't change. But still id't be good to have a sense of whether a given transaction succeeded or failed. So a reasonForFailure():Exception property in TransactionEvent would be great, provided post events are always thrown, both upon success and upon failure.
Thoughts? may I add post events to insert and delete transactions, and before throwing a service exception?
Cheers,
Gabriel
I've a patch for it: <http://github.com/groldan/geoserver_trunk/commit/4340a98fd0a4c04e33755b9b8cba46b631c49713>
Which allows to truncate caches only for the transaction's affected area and iif the transaction was successful: <http://github.com/groldan/geoserver_trunk/blob/081231f33b229ff17f54476a620ef260a80d7df4/gwc/src/main/java/org/geoserver/gwc/GWCTransactionListener.java>
Comments?
Cheers,
Gabriel
On Aug 17, 2010, at 5:59 PM, Gabriel Roldan wrote:
Hey all,
I'm in the process of avoiding GWC to whip out the whole layer cache upon every transaction.
To that end, I need to make good use of transaction events, but to make _good_ use of them I'd need two things:
- first, currently only update transactions issue post events. Insert, update and delete issue pre events.
- second, it'd be great that post events were always thrown. I think the rationale behind not issuing post events for insert and delete is that the affected features won't change. But still id't be good to have a sense of whether a given transaction succeeded or failed. So a reasonForFailure():Exception property in TransactionEvent would be great, provided post events are always thrown, both upon success and upon failure.
Thoughts? may I add post events to insert and delete transactions, and before throwing a service exception?
Cheers,
Gabriel
Gabriel Roldan ha scritto:
Hey all,
I'm in the process of avoiding GWC to whip out the whole layer cache upon every transaction.
To that end, I need to make good use of transaction events, but to make _good_ use of them I'd need two things:
- first, currently only update transactions issue post events. Insert, update and delete issue pre events.
- second, it'd be great that post events were always thrown. I think the rationale behind not issuing post events for insert and delete is that the affected features won't change. But still id't be good to have a sense of whether a given transaction succeeded or failed. So a reasonForFailure():Exception property in TransactionEvent would be great, provided post events are always thrown, both upon success and upon failure.
Thoughts? may I add post events to insert and delete transactions, and before throwing a service exception?
As you realized the reason for post and pre events is to give the
transaction listener a service, changing that would be a regression.
If you need to know about the transaction completion status why don't
you just implement TransactionPlugin (a TransactionListener sub-interface), that gives you the transaction completion hooks?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
I didn't implement TransactionPlugin instead because... I didn't even know about it, believe it or not 
Sounds like a perfect match, thanks for the info Andrea.
Gabriel
On Aug 19, 2010, at 8:47 AM, Andrea Aime wrote:
Gabriel Roldan ha scritto:
Hey all,
I'm in the process of avoiding GWC to whip out the whole layer cache upon every transaction.
To that end, I need to make good use of transaction events, but to make _good_ use of them I'd need two things:
- first, currently only update transactions issue post events. Insert, update and delete issue pre events.
- second, it'd be great that post events were always thrown. I think the rationale behind not issuing post events for insert and delete is that the affected features won't change. But still id't be good to have a sense of whether a given transaction succeeded or failed. So a reasonForFailure():Exception property in TransactionEvent would be great, provided post events are always thrown, both upon success and upon failure.
Thoughts? may I add post events to insert and delete transactions, and before throwing a service exception?
As you realized the reason for post and pre events is to give the
transaction listener a service, changing that would be a regression.
If you need to know about the transaction completion status why don't
you just implement TransactionPlugin (a TransactionListener sub-interface), that gives you the transaction completion hooks?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers
So far so good, I _could_ live with TransactionPlugin instead of a more convoluted TransactionListener, but the problem is that the only kind of post events sent to TransactionListener/Plugin.dataStoreChange, POST_UPDATE, does not come with a "source". All other events (PRE_INSERT/UPDATE/DELETE) have the TransactionEvent.getSource() property set (and being the EObject representing the transaction element: InsertElementType, etc).
Is there a reason for pos-update events not having the source property set? I'd really really need it.
Cheers,
Gabriel
On Aug 19, 2010, at 11:27 AM, Gabriel Roldan wrote:
I didn't implement TransactionPlugin instead because... I didn't even know about it, believe it or not
Sounds like a perfect match, thanks for the info Andrea.
Gabriel
On Aug 19, 2010, at 8:47 AM, Andrea Aime wrote:
Gabriel Roldan ha scritto:
Hey all,
I'm in the process of avoiding GWC to whip out the whole layer cache upon every transaction.
To that end, I need to make good use of transaction events, but to make _good_ use of them I'd need two things:
- first, currently only update transactions issue post events. Insert, update and delete issue pre events.
- second, it'd be great that post events were always thrown. I think the rationale behind not issuing post events for insert and delete is that the affected features won't change. But still id't be good to have a sense of whether a given transaction succeeded or failed. So a reasonForFailure():Exception property in TransactionEvent would be great, provided post events are always thrown, both upon success and upon failure.
Thoughts? may I add post events to insert and delete transactions, and before throwing a service exception?
As you realized the reason for post and pre events is to give the
transaction listener a service, changing that would be a regression.
If you need to know about the transaction completion status why don't
you just implement TransactionPlugin (a TransactionListener sub-interface), that gives you the transaction completion hooks?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers