Revision as of 09:38, 3 December 2021 edit Frap (talk \| contribs) Extended confirmed users, File movers, Pending changes reviewers, Rollbackers 35,585 edits →C#: use file-scoped namespace ← Previous edit		Revision as of 18:29, 25 May 2022 edit undo Hunan201p (talk \| contribs) Extended confirmed users 20,357 edits No edit summary Next edit →
Line 35: == Pitfalls == Care must be taken to ensure the state of the objects returned to the pool is reset back to a sensible state for the next use of the object, otherwise the object may be in ana state unexpected by the client, which may cause it to fail. The pool is responsible for resetting the objects, not the clients. Object pools full of objects with dangerously stale state are sometimes called object cesspools and regarded as an [[anti-pattern]]. Stale state may not always be an issue; it becomes dangerous when it causes the object to behave unexpectedly. For example, an object representing authentication details may fail if the "successfully authenticated" flag is not reset before it is reused, since it indicates that a user is authenticated (possibly as someone else) when they are not. However, failing to reset a value used only for debugging, such as the identity of the last authentication server used, may pose no issues.

Object pool pattern: Difference between revisions