cayenne-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrus Adamchik (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CAY-1173) Expose QueryLogger invocations as events
Date Mon, 06 Apr 2009 10:42:12 GMT

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

Andrus Adamchik commented on CAY-1173:
--------------------------------------

Finally got around to looking at this patch. I am ok with the general direction taken, however
things look a bit spread out. It was my idea to tie some stats collection to OperationObserver,
and now it seems rather clunky. Maybe try an approach tying everything to the dedicated transaction-stored
object. Also let's try to do things step by step, so that the patches are easier to evaluate
and test. 

So step 1 would be to collect the right statistics without touching QueryLogger or sending
any new events. Here is the possible API for doign that:

class Transaction {
   StatisticsManager getStatisticsManager();
}

/** 
* Collects operation statistics. Tied to the single transaction thread and 
* therefore can keep intermediate statistical state, reset at the end of the transaction.
*/
class StatisticsManager { 
     void transactionStarted();
     void transactionFinished();
  
     void actionStarted(/* action info */);
     void actionFinished();
   
     void actionUpdatedRows(int);
     void actionReadRows(int);
} 

> Expose QueryLogger invocations as events
> ----------------------------------------
>
>                 Key: CAY-1173
>                 URL: https://issues.apache.org/jira/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, innitial_steps_log_ProcedureAction_cmline.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.


Mime
View raw message