[Glass] Refrence to anObject

Dario Trussardi dario.trussardi at tiscali.it
Mon Jun 16 04:54:43 PDT 2014 

Ciao,

> On Jun 13, 2014, at 11:26 AM, Dario Trussardi <dario.trussardi at tiscali.it> wrote:
> 
>> Ciao,
>> 
>>>> 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. 
>> 
>> No, i only have topaz session.
>> 
>> The GemTools session is logout and i don't have gems request ( web request ).
> 
> What do you get from ‘System currentSessionNames’?
> 
>> I need to down the gems  in any case ? 
> 
> If you are the only user gem (SymbolGem and GcGems are fine), then things should work. You should not need to stop any non-user (system) gems.
> 
>> I restart the stone and resubmit all the command and waiting, it's work fine.
> 
> Glad to hear that everything is working as expected now.
> 
>>>> For testing  i control the instances of one class 	before A)	 and after B):		MARecordSessioneModel allInstances size.
>>>> 
>>>> 	It's answer the same 39 items.
>> 
>> But 		aClass allInstances	 return only relative live object or all ( live - dead - and shadow instances ) ?
> 
> The scan of the repository for instances of a class is done using the most recent object table. Thus, it finds the current version of all instances of a class; shadow instances are ignored since they are not referenced by the current object table. The object table does not know if an object is referenced, so the live/dead status is ignored.
> 
>> It's wrong working on the instances of one class basing on 	aClass allInstances   code
> 
> I’m not sure what is wrong.

Not wrong, but not reliable, because it work on live and dead object, as you write:

	  "The object table does not know if an object is referenced, so the live/dead status is ignored."

	In any case i can test if the aObject is live with:   	SystemRepository findReferencePathToObject:	aObject

	Right?

> 
>>>> 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).
>> 	
>> 	But the GC Gems as identifies the dead and shadow objects?
>> 
>> 	7) One or more Reclaim GcGems reclaims pages: it copies live objects on the page onto a new page, thereby compacting live objects in page space. The page now contains only recycleable objects and perhaps free space.
>> 	Reading i thinks the dead marked is only do by MFC, i wrong?
>> 
> Dead marking is done only by one of the garbage collection processes: (1) MFC, (2) Epoch, or (3) offline. 

What you intend for offline? 
	
	 A restore from backup ?

Thanks,

		Dario

> 
>> 	The GC Gems  do only the reclaims pages ?
> 
> The GcGems do reclaims for both shadow and dead objects.
> 
>> 
>> 	Thanks,
>> 
>> 		Dario
>> 
>>> 
>>> 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
>>>>> 
>>>> 
>>> 
>> 
>> _______________________________________________
>> 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/20140616/f8d23bac/attachment-0001.html>

More information about the Glass mailing list