There a couple typical cases for a "memory leaks". (I put memory leak in quotes, because the system does eventually recover the memory, it just has to wait for the bean to timeout. Typically a few hours, if I recall.) The first potential leak is when the user just closes their browser window without reaching an end or a postpone. This usually isn't a big deal: the system will eventually get the memory back and majority of the time the users will do the right thing and go to the postpone/end. A few exceptions won't be a problem. The more nefarious case is when a BPM author tries to be tricky and deliberately creates a coach that doesn't end. For example, when generating a coach based report. Or when creating a coach that issues a redirect to an external web page. This is nefarious because this "leak" will happen every time that service is used and therefore can happen much more frequently in aggregate. These are often referred to as "never ending services" in some of the performance documents. This isn't to say that you should never create these kinds of services, just that you need to be aware of the memory consequences.
So, some general advice on memory:
- Most importantly, don't keep variables around longer than you need them. If you get a big XML document back from the integration service, and then you parse than XML into BPM variables, set the XML document to null once you are done with it. This not only minimizes the amount of memory you are keeping in the session but also minimizes the data that is being saved and loaded to the database with every execution context save.
- Don't have data in the service that you don't need. This is somewhat of a corollary to the previous one, but only send the objects to the service that are needed. No sense in sending data from the BPD to the service if it isn't needed.
- Avoid never ending services when you can.
- If you must have a never ending service (and there may be times that you do need to create), then make sure to null out all of the variables and be very conscious of your memory usage. For example, if you are creating a coach based report that will not "end", you can use a custom HTML block at the end of the page to null out all of the variables used to create the report.
- Encourage users to use postpone buttons rather than just closing the browser window. Not only does it save memory but it also ensures that the user's data is saved