I know people have used YourKit for things like this but it's not exactly clear in showing anything orphaned..

Honestly I wouldn't lose sleep over it.  You want to be REALLY careful in loops of course.  Most things will get auto recycled eventually when the code ends.  You do want to be a little careful on things like DateTime which actually spawn from session.  So they can hold on longer.  

My understanding is you do NOT need to recycle session or database ever....  

If you're really are worried then maybe go into the OpenNTF Api or some of Tim's old projects and you might find an incinerate method that they use for recycling.  To make it easy. If you can find that and pull it into your own stuff that might help. Remember just because in your application you can't use the whole API doesn't mean you can't pull some pieces out if needed.

Good Luck

I know when developing I have been able to eventually bring my server to a virtual stand still when methods crash part way through and leave stuff stranded because they never get to the recycle. when things terminate properly there seems to be a lot fewer issues.

The only time I really had a problem with recycling that I remember...  before the API...  was on my cheatsheet site I did an export to excel demo of like 50,000 names...  and without recycling that would crash the server often.

This is probably a better question for the techy's on StackOverFlow.

Another thing to consider though...  depending on the application usage...  you might want to implement caching of your objects.  

so it's all well and good that we're getting into Java right?  but as we do so we're making LOTS of objects....  

Let's say I have a help ticket application...  and in that application there's a field that lists my company's 50 locations.  So you can set the current location on the ticket.  simple enough.

In Java maybe you create a Location.class so provide getters and setters to the address... phone, number, key value... whatever...

Then you make another class like a "LocationSet.class" to combine them all and feed into the dropdown...  

So now user a opens a ticket...  a LocationSet is created and it's populated with 50 Location Objects.  So you just made 51 Objects...  (at least)...  depending on what else is inside them.

Now user 2 comes in and opens another ticket... so it creates a LocationSet and populates the 50 Location Objects.

Even though your company only has 50 physical locations...  your server is keeping track of 100 location objects...  (and 2 different location sets)....

I guess I'm just suggesting that if you're having problems...  MAYBE it's not all about recycling but it could be creating way more objects then are necessary and you might need to add a caching system to keep the objects down.  

Just a guess really...

Good Luck

Dave

That would be an argument for an applcation scope bean as well would it not. I have created a couple of them one keeps all my tooltips in an application scope bean. I'm not sure what it is doing for anything else but man it really sped up the tooltips. I store the tool tips in a help database and each tooltip did a lookup into the help DB. Now one build of the bean and the rest is pretty smooth.

I'm sure you could use an appScope bean as an application level cache.  A server one would work with multi-nsf's but if you're only dealing with one then I can see that.

The appScope bean would I guess need to be like a Factory...  generating or storing any objects you create to you can get them back again.  I think all you'd need then is to make sure the objects were truly singletons which should be doable.

Interesting...

..so once loaded it remains pretty much the same for long periods of time so the ApplicationScope Object is loaded once and once an application is developed and running everything is just a call to the Bean to get the piece of information that I need. For example I have a "Master" database and in it I have any number of Application Documents. So the Master can be a 'portal' to any number of Applications. The application documents contain a number of values that describe the Application such as the RepID of the application database, and at the present time about 10 or 12 other bits of information like the "default View" the XPage to load etc. So if the Main Application is made 10 sub applications I load those 10 -12 pieces of information about the Sub App into a Map -- public class ApplicationMap implements Serializable, Map<String , AppProperties> -- I store the Application I'm working with in a sessionScope variable so I can always call the appProps bean and get back any value from the AppProperties. Works like a charm and makes the Master Application extensible to virtually any number of Sub Applications.

So in my Workflo!Approval master database it points to a number of sub Apps like Contracts, PR Requests, Vacation Requests, New Hire Approval, Sample Request each with it's own data structure but using the common processes from the master DB. The other major advantage is that if I update the design of the Master it only needs to be done in one place. In my Native Notes application the customer might have 10 or more copies of the Application installed and I have no idea if they are all running with the latest code. I'm in final Beta with my Workflo!Approval for XPages and it looks pretty good right now.

Yeah, make sure objects in your loops recycle. Ive monitored agents before, the loops are the issue that really cause serious memory losses.