The Resource Timer pattern has the following consequences:

Automatically cleans up inactive resources— Resource Timer defines a strategy for mitigating the negative effects on system utilization and performance incurred by defective applications and neglectful users that leave resources open indefinitely.
Requires minimal changes to application code— Assuming that application code is written in terms of generic resource interfaces, replacing concrete implementations with timers only requires changes to resource initialization routines.

Unintentional timeouts— There are cases when an application or user really intends to keep a resource open and inactive beyond its configured inactivity threshold. These cases are difficult to identify and accommodate. If you anticipate this requirement, it is best to ensure that your application's configuration allows this functionality to be disabled in special cases.
Increased thread complexity and overhead— Many timer implementations involve some semblance of a timing thread. It is common to create a thread for every timed resource in the system. Threads add complexity and overhead of their own and can contribute to system scalability issues if you do not manage them diligently.