Re: [Dev] Clarification regarding primary keys of LOGANALYZER table

2016-09-01 Thread Inosh Goonewardena
+1 for removing primary keys which prevents from storing all the log entries. Btw, you can avoid deadlocks from happening in this kind of scenario by setting transaction isolation level to Read Uncommitted in datasource configuration (dirty reads may occur due to this but it won't be an issue in

Re: [Dev] Clarification regarding primary keys of LOGANALYZER table

2016-09-01 Thread Ruwan Abeykoon
Hi Tishan, Thanks for the findings. +1 for option 2 :Remove primary keys and just keep indexes. I guess there will be few issues if we ever want to do log-tail submission. But we can find a solution for that too later, as log-tail is not going to be used as of now. Cheers, Ruwan On Thu, Sep

[Dev] Clarification regarding primary keys of LOGANALYZER table

2016-09-01 Thread Tishan Dahanayakage
Hi all, While doing performance tests on log analyzer I came across a DB deadlock issue when bursting event. Root cause for the issue is as follows. - I have different set of log entries(~10) which I loop around continously and publish with current timestamp. - Currently _class, _content, _level,