Revision as of 16:43, 21 November 2007 edit Ruijoel (talk \| contribs) 54 edits →C# Examples: fixed grammatical error. Modified last sentence. ← Previous edit		Revision as of 16:45, 21 November 2007 edit undo Ruijoel (talk \| contribs) 54 edits →Pitfalls: minor rephrasing Next edit →
Line 13: == Pitfalls == When writing an object pool, the programmer has to be careful to make sure the state of the objects returned to the pool is reset back to a sensible state for the next use of the object. ~~Often if~~If this is not observed, the object will often be in some state that was unexpected by the client program and ~~that~~ will cause the client program to fail. ~~Usually, the~~The pool is responsible for resetting the objects, not the clients. Object pools full of objects with dangerously stale state are sometimes called object [[cesspit\|cesspools]]. The presence of stale state is not always an issue; it becomes dangerous when the presence of stale state causes the object to behave differently. For example, an object that represents authentication details may break if the "successfully authenticated" flag is not reset before it is passed out, since it will indicate that a user is correctly authenticated (possibly as someone else) when they haven't yet attempted to authenticate. However, it will work just fine if you fail to reset the identity of the last authentication server used, since this is only used for debugging.

Object pool pattern: Difference between revisions