Maybe just put
log4j.logger.er.transaction.adaptor.EOAdaptorDebugEnabled=DEBUG
And a conversion pattern with milliseconds like
log4j.appender.A1.layout.ConversionPattern=%d{HH:mm:ss.SSS} %-5p (%F:%L) - %m%n
In your properties file?
Ramsey
On Apr 17, 2012, at 7:43 AM, Kasper Frederiksen wrote:
> Hi All,
>
> So I am looking for bottlenecks to explain slow response times in a Web
> Objects server application and I have come up with the following plan for
> monitoring database access. I am not sure this is the best way to do it,
> please let me know what you think.
>
>
> I extend WOApplication and in the constructor I set a new delegate to the
> EODatabaseContext and add an observer to NSNotificationCenter:
> ---
> MyDelegateAndObserver myDelegateAndObserver = ...
> EODatabaseContext.setDefaultDelegate(myDelegateAndObserver);
> NSNotificationCenter.defaultCenter().addObserver(
> myDelegateAndObserver,
> new NSSelector("hookIntoChannel", new Class[] {NSNotification.class}),
> EODatabaseContext.DatabaseChannelNeededNotification,
> null);
> ---
>
> In the class MyDelegateAndObserver I defined "hookIntoChannel" from above and
> the methods to capture notifications:
> ---
> public void hookIntoChannel(NSNotification not){
> final EODatabaseContext dbctxt = (EODatabaseContext)not.object();
> final EODatabaseChannel channel = new EODatabaseChannel(dbctxt);
> if(channel != null){
> channel.adaptorChannel().setDelegate(this);
> dbctxt.registerChannel(channel);
> }
> }
>
> public boolean adaptorChannelShouldEvaluateExpression(EOAdaptorChannel
> channel, EOSQLExpression expression){
> /* thread safe logging: start of database round trip */
> return true;
> }
>
> public void adaptorChannelDidEvaluateExpression(EOAdaptorChannel channel,
> EOSQLExpression expression){
> /* thread safe logging: end of database round trip iif expression is
> UPDATE or INSERT */
> }
>
> public NSArray databaseContextDidFetchObjects(EODatabaseContext dbCtxt,
> NSArray results, EOFetchSpecification fetchSpec, EOEditingContext ec){
> /* threadsafe logging: end of database round trip for SELECT */
> return null;
> }
> ---
>
> I store the above logging in a java.lang.ThreadLocal and once the WO request
> is about to return (listen for
> WOApplication.ApplicationDidDispatchRequestNotification) I can sum up the
> number of database accesses and the total time spent waiting for database IO.
>
> Two thing worry me about this approach:
> 1) I am overwriting the DatabaseContext default delegate with a custom
> delegate that will always answer adaptorChannelShouldEvaluateExpression=true
> 2) What kind of overhead am I looking at here ... I suppose I will find out,
> but does this look like the kind of code you would include in a production
> environment application?
>
> I appreciate your input
> -Kasper Frederiksen
>
>
> ps.
> I could not find this in the documentation so this is based on empirical
> evidence :). This is the life cycle of a database access as seen from the
> notifications sent to DatabaseContext and AdaptorChannel. I have noted where
> I have chosen to consider the closest points to the start/end of the database
> IO for the purpose of logging time spent.
>
> For a SQL SELECT
> ===
> 1) databaseContextShouldFetchObjects:
> 2) databaseContextShouldSelectObjects:
> 3) adaptorChannelShouldSelectAttributes:
> 4) adaptorChannelShouldEvaluateExpression: start of database access
> 5) adaptorChannelDidEvaluateExpression:
> 6) adaptorChannelDidSelectAttributes:
> 7) adaptorChannelWillFetchRow:
> 8) adaptorChannelDidFetchRow: 7 and 8 may be repeated a number of times
> 7) adaptorChannelWillFetchRow:
> 9) adaptorChannelDidFinishFetching:
> 10) databaseContextDidFetchObjects: end of database access
>
> For a SQL UPDATE or INSERT
> ===
> 1) adaptorChannelWillPerformOperations:
> 4) adaptorChannelShouldEvaluateExpression: start of database access
> 5) adaptorChannelDidEvaluateExpression: end of database access
> 6) adaptorChannelDidPerformOperations:
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list ([email protected])
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com
>
> This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
