[GemStone-Smalltalk] objectForOop: question about some errors we get + how to implement a weak reference?

[Martin McClure]

On 7/25/22 08:29, Johan Brichau wrote:
> Hi Martin,
>
> Thanks for that extensive feedback!
> I think this is going to help us in finding a solution here.
Hi Johan,
Glad to hear that.
>
> Besides checking for oopIsDead: first, we’re thinking of completely 
> avoiding the problem by keeping the ‘deleted’ objects connected for 
> the time that the user log displays actions in the past. We can then 
> remove them later on when it’s safe to do so.
If an object never becomes disconnected while a user log might display 
it, that should avoid the problem.
>
> Given that I noticed that the problem disappeared without a gem 
> crash/restart: do you think it would also be ok to just capture the 
> ObjDoesNotExist error and do nothing with it?
> That would allow us to prevent an entire crash of the application 
> session while we create a solution to prevent the error altogether.
It probably is OK to ignore the error and then not try to use the object 
that caused the error, as long as you can identify which object that is.
>
> Because it does look like we are doing things in such a way that make 
> it is more likely for this case to appear….
>
> The objectForOop: is used in code that is continuously executed (i.e. 
> every minute for every user session in our Seaside app) because it 
> displays the list of user actions that happened in the last xxx hours 
> in the application.
> Because ‘delete actions’ are definitely on that ‘user action log’, the 
> oops that are retrieved can be of disconnected/dead objects.
> We notice that many of our users just keep their app session logged-in 
> overnight and therefore this gets executed many times concurrently 
> with an MFC+reclaim run.

I agree that this pattern is more likely to get this kind of error. I'd 
recommend keeping deleted objects referenced, in the log or elsewhere, 
until xxx hours have passed. Which is what you were describing above, I 
think?

> Finally, the Seaside error handler logs the continuation of the error 
> to the objectLog, so a commit happens when the dead object retrieved 
> via the objectForOop: is on the stack. In fact, because the 
> continuation is saved, it is probably even committed again?
I don't immediately know whether it would be possible to commit a 
reference to the disconnected or dead object. Maybe. At certain times in 
the GC process committing a reference to a disconnected object would 
connect it and keep it from being GCed. After the object was promoted to 
dead, if a reference to that oop succeeded in being committed, you'd end 
up with a reference to a non-existent object. Eventually if that OOP was 
reused it would become a reference to the new object. Generally a 
situation to avoid. In your case it sounds like these objects are parts 
of object graphs that are considered "deleted" by your application, so 
are less likely to cause problems.

Regards,
-Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/archives/gemstone-smalltalk/attachments/20220725/dcd8d7fe/attachment-0001.htm>