[
https://issues.apache.org/cayenne/browse/CAY-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anatol Lutski updated CAY-1173:
-------------------------------
Attachment: innitial_steps_log_ProcedureAction.txt
After applying of the patch the code won't compile. But it demonstrates the
main idea of implementation.
> Expose QueryLogger invocations as events
> ----------------------------------------
>
> Key: CAY-1173
> URL: https://issues.apache.org/cayenne/browse/CAY-1173
> Project: Cayenne
> Issue Type: Improvement
> Components: Cayenne Core Library
> Affects Versions: 3.0M5
> Reporter: Andrus Adamchik
> Assignee: Andrus Adamchik
> Attachments: innitial_steps_log_ProcedureAction.txt
>
>
> With JMX in mind, I am thinking how to expose Cayenne stack statistics to the
> outside observers. There are many parameters that can be monitored in
> Cayenne. For the purpose of this task we are limiting the scope on low level
> JDBC operations, such as running queries and updates, and reading result
> sets, i.e. a subset of what QueryLogger logs.
> Suggested approach to this problem is to replace direct calls to QueryLogger
> from everywhere in the code to an event mechanism, with a logging listener
> delegating to QueryLogger (for a fully backwards compatible behavior), and an
> *optional* statistics listener that can be exposed via a JMX MBean interface.
> Now QueryLogger has a bunch of methods that we should not expose as events.
> Those we can keep calling directly. I'd like to concentrate on the following
> methods:
> logQuery(String queryStr, List<DbAttribute> attrs, List<?> params, long time)
> logSelectCount(int count, long time)
> logUpdateCount(int count)
> logQueryError(Throwable th)
> logGeneratedKey(DbAttribute attribute, Object value)
> logCommitTransaction(String transactionLabel)
> logRollbackTransaction(String transactionLabel)
> logQueryParameters(String label, List<DbAttribute> attrs, List<Object>
> parameters, boolean isInserting)
> I am not entirely happy with QueryLogger API. The events may be a little more
> generic than what we are using for logging (but we should be able to derive
> current logging info from them). E.g. we can have something like this:
> DataNodeListener:
> - queryStarted(QueryStartEvent event)
> - queryFinished(QueryFinishEvent event)
> QueryStartEvent:
> - Query getQuery()
> - String getTranslatedQuery()
> - QueryParameters getQueryParameters() // account for simple queries and
> batches .. may have a List<List<DbAttribute>> vs. List<List<Object>> or
> something like that...
> - long getTimestamp()
> QueryFinishEvent:
> - boolean isCommitted() // true if committed false if rolled back
> - Throwable getException() // for rolled back queries
> - long getTimestamp() // comparing start and finish timestamps on a
> given thread should give a query run time
> - int getSelectedRowsCount()
> - int getUpdatedRowsCount()
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
