On 11/02/2009, at 5:26 PM, Andrus Adamchik wrote:
> The general idea was to expose the points where logging currently
> occurs via an event mechanism that we can continue to use for
> logging, but also for any other purpose (some yet unforeseen). The
> underlying motivation was indeed to build performance monitoring
> tools beyond simple logging. So the next step, after the right
> events are in place will be to provide a "JMX listener" to use Java
> JMX mechanism to expose basic query stats.
Would Cayenne keep aggregate statistics (min/av/max/count) tracked
internally? That would make it easy for a user to monitor for slow
selects without writing a listener at all.
> It should be possible to do JDBC-level audit with this approach,
> however currently there's no link back to the objects being changed.
> On each update/insert/delete the event will expose a
> PreparedStatement SQL string and a map of parameters, with keys
> being column names. So not sure how useful this really is for audit
> (??) Although this whole thing will be tied to Cayenne thread
> transaction object, so theoretically you can store stuff in the
> transaction related to ObjectContext and tie that to the JDBC events.
It would seem that logging at that level for audit purposes is
probably just as easy to achieve in the database itself with less
work, so perhaps auditing is not a good use for the new QueryLogger
events. Lifecycle events are a better place to put that.
Is there a symmetry between Lifecycle events which track the progress
of an object entity, and these QueryLogger events which track what
happens to the database (although not db entities?)?
Would QueryLogger listeners be something to be configured in the
modeler?
Ari Maniatis
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
This archive was generated by hypermail 2.0.0 : Wed Feb 11 2009 - 01:51:29 EST