0

We are using a custom login handler (the license pool manager) to ensure that we always reserve some logins for our webservice users. However we noticed a lot of long running queries on our system$user table where it only updated the changed date of the user? I tried reproducing this issue using a normal login but was unable to do so. This made me wonder, does a custom login handler commit a user by default, and so update it's changed date? Another thing i noticed is that the Check method of the UserActionListener is not called when you disable check security in the modeller. While to us this is of no importance ( we don't care about the max webservice users) it was something i did not know off. Even though it makes sense ;] Edit: After doing some more tests it appears that it is not the custom login handler that is causing the issue. When i make my own custom request handler in a separate project it does not perform this problem. Would there be a way to detect where a commit comes from? Like showing the current runtime requests? Edit2: I am pretty sure now that it is not the custom login handler that causes this issue. but i am still not able to track it down. Is there any option to trace commits or to enable the show current runtime request like on the server? Edit3: I found it, It appeared we had a before commit event that changed the account. Because no actual changes were made, e.g. the references stayed the same only the changed date was set. So wrapping up it appears that on login before commit actions are always triggered and (this is more of a guess) changing references to the same reference cause an optimization to remove them from the update query.

asked 2015-06-26

1 answers