[Glass] Refrence to anObject

[James Foster]

On Jun 13, 2014, at 9:45 AM, Dario Trussardi <dario.trussardi at tiscali.it> wrote:

> Ciao James,
> 
>> On Jun 12, 2014, at 6:37 AM, Dario Trussardi <dario.trussardi at tiscali.it> wrote:
>> 
>>> Ciao,
>>> 	i have a GLASS 3.1.0.4  repository where i store some data.
>>> 	Now i need do clear the repository, 
>> 
>> How “clear” do you want the repository to be? If you want to get rid of all the data but keep the code, it might be cleaner to just load the code into a fresh repository.
> 
> 	I intend to remove obsolete objects,  hold client documents and relative reference.
>> 
>>> but i have some instances for which i don't  " know  " the pointer on it.
>>> 	I can use 	NameOf Class	allInstances    to define all relative instances.
>>> 	Now my questions are:
>>> 	A)	there is way to define  the object  that reference a given object?
>> 
>> The GemStone Programming Guide (http://downloads.gemtalksystems.com/docs/GemStone64/3.1.x/GS64-ProgGuide-3.1.pdf) has a nice discussion on “Finding Instances and References” starting on page 214. If you take a look at the class Repository (the singleton is available as the global SystemRepository), and the method categories “Listing Instances” and “Listing References.” 
>> 
>>> 	B) if i have an object with an istance variable ( call dictionaryA )  set to a  Dictionary  ( which have some asssociations )
>>> 		and i reset the the dictionaryA to:  	 Dictionary new
>>> 		it is sufficient to have the "domino"  effects relative to the hold associations?
>> 
>> The GemStone System Administration Guide (http://downloads.gemtalksystems.com/docs/GemStone64/3.1.x/GS64-SysAdminGuide-3.1.pdf) has a chapter on garbage collection that includes a description of what gets cleaned up in GC activity. Page 303 explains, "An object is dead if it cannot be reached from the AllUsers root object. Other dead objects may refer to it, but no live object does. Without living references, the object is visible only to the system, and is a candidate for reclaim of both its storage and its OOP. “ I also recorded a lecture on this topic. See items 19-22 at https://programminggems.wordpress.com/2010/02/05/scaling-objects-videos/.
>> 
>> Hope that helps,
> 
> With topaz i submit  	A)	SystemRepository markForCollection 		and it answer:	found 1058959 live object 	518925 dead objetcs.
> 
> After i submit 		B)	SystemRepository reclaimAll		and it seems work fine.
> 
> But after if i resubmit the A) 	it answer the same 	data.
> 
> I  need do other commands?

Were there other sessions logged in at the time? Also, there is an issue in 3.1.0.x in which reclaimAll will return before the reclaim actually finishes. If there are no other user sessions logged in (SymbolGem and GcGems are needed) when you do the MFC & reclaim then it should remove all the dead objects, but you might need to wait 5-10 minutes to let the reclaim actually finish. 

> For testing  i control the instances of one class 	before A)	 and after B):		MARecordSessioneModel allInstances size.
> 
> 	It's answer the same 39 items.
> 
> If i do:		SystemRepository findReferencePathToObject:		anMARecordSessionModel		it answer an Array with 2 element  where second is set to false.
> 
> 	The result of this method is an array, with the first two elements consisting of the search object and true or false indicating if a reference path was found.
> 	No reference path means that the object would be garbage collected by the next MFC
> Questions	A)	Because the MFC  and reclaimAll don't remove these instances?
> 
The MFC and reclaimAll should remove all the dead objects, but you might need to wait 5-10 minutes to let the reclaim actually finish in 3.1.0.x. We believe that the reclaimAll will be done by the time it returns in 3.2.x.

> Questions	B)	Into a production system the MFC   required external command or the system can manage it automatically ?

The MFC is a “heavy” operation and we leave it to the DBA to determine when to do it. It is not done automatically.

> Questions 	C)  	The System startAllReclaimGcSessions	  if i right understand work in foreground, but how many CPU load required?

The reclaim GC Gems are new OS processes that work in the background. They will take some CPU load but the main load is on disk. In any case, you should not generally need to manage the Reclaim Gems, you should have them running when you start the stone and they should be running all the time.

> 					it not required the SystemRepository markForCollection 	operation?

The MFC is a separate operation from reclaim. While the MFC could run without the reclaim gems, that would be unusual. You should have no reason to stop the reclaim gem(s).

James

> Thanks in advanced, 
> 
> 		Dario
>  
> 
>> 
>> James
>> 
>>> 	Thanks for any considerations.
>>> 
>>> 	Dario
>>> 
>>> 	P.S. Where i can found a valid explanation about garbage collection of the instances ?
>>> 
>>> 	I write some code but i don't considered this problematic.	Now it's time for it
>>> _______________________________________________
>>> Glass mailing list
>>> Glass at lists.gemtalksystems.com
>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140613/112110ff/attachment.html>