[
https://issues.apache.org/jira/browse/CAY-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrus Adamchik closed CAY-1173.
--------------------------------
Resolution: Won't Fix
Stale. Closing
> Expose QueryLogger invocations as events
> ----------------------------------------
>
> Key: CAY-1173
> URL: https://issues.apache.org/jira/browse/CAY-1173
> Project: Cayenne
> Issue Type: Improvement
> Components: Core Library
> Affects Versions: 3.0M5
> Reporter: Andrus Adamchik
> Assignee: Andrus Adamchik
> Priority: Major
> Fix For: Undefined future
>
> Attachments:
> 0001-CAY-1173-Expose-QueryLogger-invocations-as-events.patch,
> innitial_steps_log_ProcedureAction.txt,
> innitial_steps_log_ProcedureAction_cmline.txt, statistics_manager_base.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 was sent by Atlassian Jira
(v8.20.10#820010)
