If I open a database connection using ucanaccess it creates an instance of DBReference, which in turn creates an instance of MemoryTimer, which creates an instance of Timer - which creates a new thread.
When the connection is closed DBReference.Shutdown is called, but it never cancels the Timer created in the instance of MemoryTimer, so this thread is never removed.
In most cases not a big deal, but in my usage I only use the connection in single instance mode so it is regularly connected and disconnected, it does not take long for me to ring up 40 timer threads...
A couple of things off here that I can see
1) The MemoryTimer instance should not be created on startup, it should be created (or not) when the DBReference.setInMemory() is called.
2) When the DBReference.Shutdown is called, it should check to see if a MemoryTimer instance exists and if so it should cancel the timer created inside that object.
I would also suggest moving to github with this project I could create a PR for this pretty quickly..
Thanks for your work with this
Nz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Firstly, thank you for your analysis in depth.
Maybe I need some more analysis, but as first instance:
I wouldn't agree with bullet 1: this mechanism is used to recover filesystem resources as well.
I agree with bullet 2.
In general a just timer is created for each db connected(it doesn't matter how much connections you establish to a given db).
The memory leak you report may have effect:
- using the single connection mode if you're connecting to multiple databases (if the db connected is always the same you shouldn't use the single connection mode).
-in the case continous update by another process
-in the case of pooling on the db ith intervals greater than 2 minutes (because of the default, but a work around would be chenge the connection parameter InactivityTimeout, i.e., InactivityTimeout=0).
I think that at the DBReference.Shutdown, when the REference instance is removed, the related timer must be accordingly canceled. It will be fixed in the next release.
Moving to github? I'll think about it.
Thank you!
Last edit: Marco Amadei 2015-05-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If I open a database connection using ucanaccess it creates an instance of DBReference, which in turn creates an instance of MemoryTimer, which creates an instance of Timer - which creates a new thread.
When the connection is closed DBReference.Shutdown is called, but it never cancels the Timer created in the instance of MemoryTimer, so this thread is never removed.
In most cases not a big deal, but in my usage I only use the connection in single instance mode so it is regularly connected and disconnected, it does not take long for me to ring up 40 timer threads...
A couple of things off here that I can see
1) The MemoryTimer instance should not be created on startup, it should be created (or not) when the DBReference.setInMemory() is called.
2) When the DBReference.Shutdown is called, it should check to see if a MemoryTimer instance exists and if so it should cancel the timer created inside that object.
I would also suggest moving to github with this project I could create a PR for this pretty quickly..
Thanks for your work with this
Nz
Firstly, thank you for your analysis in depth.
Maybe I need some more analysis, but as first instance:
I wouldn't agree with bullet 1: this mechanism is used to recover filesystem resources as well.
I agree with bullet 2.
In general a just timer is created for each db connected(it doesn't matter how much connections you establish to a given db).
The memory leak you report may have effect:
- using the single connection mode if you're connecting to multiple databases (if the db connected is always the same you shouldn't use the single connection mode).
-in the case continous update by another process
-in the case of pooling on the db ith intervals greater than 2 minutes (because of the default, but a work around would be chenge the connection parameter InactivityTimeout, i.e., InactivityTimeout=0).
I think that at the DBReference.Shutdown, when the REference instance is removed, the related timer must be accordingly canceled. It will be fixed in the next release.
Moving to github? I'll think about it.
Thank you!
Last edit: Marco Amadei 2015-05-14
Thanks for looking into this !
Nz