[jira] Commented: (CAY-1173) Expose QueryLogger invocations as events

["Anatol Lutski (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/cayenne/browse/CAY-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13242#action_13242 ] 

Anatol Lutski commented on CAY-1173:
------------------------------------

Patch "innitial_steps_log_ProcedureAction.txt" is an initial step of implementation. Statistics collection is shown by the example of ProcedureAction.
	The main idea is to have pair of events which will be generated in the beginning and in the end of each transaction/action execution, and also to have one event which saves logging info immediately. We need this action because it's necessary to save executable sql before start - in order to check it in the case of an error. 
	OperationObserver is present at any moment of an operation execution. So it's used as a statistics collector. 
	DefaultStatisticsCollector - a new base abstract class implementing additional functions for collecting info. All classes which now implement OperationObserver have to extends this one. (It's a reason why the code ins't compiled - cause the declaration was changed only for DataDomainQueryAction).

Some notes about classes.
New events: ActionFinishEvent, ActionStartEvent, FixInfoEvent, TrxFinishEvent, TrxStaetEvent.
EventFacade - static class, used for posting events in different places of framework.
Configuration - initialization of the listener
LoggingListener - default processor of Events.
DataNode, ProcedureTranslator - here you can see how the event which immediately saves info in log is posted
BaseSQLAction - here log info is being collected in Observer
ProcedureAction- the pair of start and finish events is generated

Please check the main idea. If everything is right I add the same logging for the rest of the actions.

> 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
>
> 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.