tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/53-cleaning-up-objects-how-does-the-di-handle-gcRobotlegs: Discussion 2013-04-28T10:29:53Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/9411922010-01-31T12:45:11Z2010-01-31T12:45:11ZCleaning up objects / How does the DI handle GC?<div><p>Sounds like your understanding of how all of this works is spot
on.</p>
<p>One thing to note it that once you change your service's mapping
from<br>
mapSingleton to mapClass, the instances that generated for
injection<br>
into your command will be garbage collected together with your
command<br>
class, as there's nothing else referencing them. The DI
container<br>
doesn' t keep any references for the injected values - except
for<br>
singletons, of course.</p>
<p>In essence, if you have a service that's only going to be used
once<br>
and that you want to have garbage collected once you don't need
it<br>
anymore, you should use Injector#unmap to remove the singleton
mapping<br>
once you're done with it. On the other hand, your service
should<br>
probably not need to be garbage collected in the first place, as
it<br>
shouldn't keep any noteworthy amounts of data around anyway.</p>
<p>Also, I'm not sure SwiftSuspenders removes singletons once
their<br>
mapping is removed; in fact, thinking about it I'm fairly certain
it<br>
doesn't. It probably should, so I'll open a ticket for that.</p>
<p>Does all of this make sense and help answering your
question(s)?</p></div>Till Schneidereittag:robotlegs.tenderapp.com,2009-10-18:Comment/9411922010-01-31T17:08:56Z2010-01-31T17:08:56ZCleaning up objects / How does the DI handle GC?<div><p>Hi tschneidereit,<br>
Thanks for the reply, that answers my question.</p>
<p><em>...the instances that generated for injection into your
command will be garbage collected together with your command<br>
class...</em><br>
Yup, that makes sense, but I guess using mapClass would not be what
I want, as that could create multiple instances/calls to the same
service.</p>
<p>Thanks for the bit about the unmap, that's definitely good to
know.</p>
<p>Agree on the last bit as well, each service I have will live
throughout the application lifetime, so it needs to be a singleton
anyway.</p>
<p>I think when I clean up everything in <strong>MyService</strong>
I'll just ignore the Injected Singletons. So if I have 10 different
services, they won't start eating up resources as they will all
have only a reference to one Object (<strong>MyModel</strong>).</p>
<p>Looking forward to the update to SwiftSuspenders. Great work by
the way!</p></div>seanlailtag:robotlegs.tenderapp.com,2009-10-18:Comment/9411922010-02-03T10:30:55Z2010-02-03T10:30:56ZCleaning up objects / How does the DI handle GC?<div><p>Hi Sean(?)</p>
<p>I use a slightly different pattern to yours:</p>
<ul>
<li>mapSingleton(MyModel)</li>
<li>mapSingleton(MyService)</li>
<li>command MyDoSomething has an injection of MyService</li>
<li>command MyDoSomething calls myService.doThing()</li>
<li>myService.doThing <strong>does not</strong> have the model
injected. It 'may' have a factory injected to produce a VO (value
object) when required.</li>
<li>myService.doThing makes a service call and then populates a
local event, MyServiceDoneEvent (in the service result handler)
with the vo(s)</li>
<li>myService dispatches the event. That's the only place a lasting
reference to the vo(s) is kept.. and not for long.</li>
<li>MyServiceDoneEvent is mapped to UpdateMyModelCommand</li>
<li>The command has an injection for MyModel. It passes
event.payload to myModel, or parses it into it.</li>
</ul>
<p>The service is REALLY light. Now you could choose to inject
MyService with mapClass and it would be disposed of after use (I
believe). In MyDoSomething (the command) map the event listener for
UpdateMyModelCommand as a one shot.</p>
<p>Hope this helps and I'm not completely off the mark :)</p></div>squeedeetag:robotlegs.tenderapp.com,2009-10-18:Comment/9411922010-03-02T16:28:01Z2010-03-02T16:28:01ZCleaning up objects / How does the DI handle GC?<div><p>To follow up on this: I've released a new beta version of
SwiftSuspenders 1.5 yesterday that fixes the problem with
singletons not being released on unmap.</p>
<p>If you want to give that version a try, you can download it here
(the first download should always be the current version):<br>
<a href=
"http://github.com/tschneidereit/SwiftSuspenders/downloads">http://github.com/tschneidereit/SwiftSuspenders/downloads</a></p></div>Till Schneidereit