Forums

by cnwjhp1 >> Mon, 18 Jul 2005 10:10:46 GMT

Consider the following:

create user transient;
app.myUser := user;

What would be wrong with changing this code to
create app.myUser transient;
or
create user appTransient;
?

I am trying to keep it as simple as possible, and I don't see why periodic checks, checks for references or whether it has been assigned elsewhere are necessary.

consider calling the method a second time, the original transient is now orphaned and will miss the AGC.

Don't understand what you mean by this.

by John Beaufoy >> Tue, 19 Jul 2005 11:08:12 GMT

Consider the following:

create user transient;
app.myUser := user;

What would be wrong with changing this code to
create app.myUser transient;
or
create user appTransient;
?

1) It does nothing for the applications already in production.
2) You have to think about memory mgmt to know which to use, is that any better than what we have now?
3) Potential issues are introduced, like attempting to passback 'method' transients
4) appTransients are still there as potential memory leaks, so how far does this go to cracking the problem?

I am trying to keep it as simple as possible, and I don't see why periodic checks, checks for references or whether it has been assigned elsewhere are necessary.

Simpler for who? This maybe more work for the Jade plant, but the result should be an AGC with no change to the code semantics we use now and one that catches most cases - which has got to be good?

consider calling the method a second time, the original transient is now orphaned and will miss the AGC.

Don't understand what you mean by this.

Overwriting references with new objects, in your example this would be calling the following two lines where oid xxx.1 is now a 'leak'

create app.myUser transient; // oid xxx.1 created
create app.myUser transient; // oid xxx.2 created

by Patwos >> Mon, 27 Jun 2005 3:38:50 GMT

I wouldn't imagine anyone using Class.firstInstance to access a transient given that this finds the first persistent instance nor would you hope to see people using Class.firstTransientInstance in mainstream production code given the overhead this takes to process.

I could however, see someone using String::asOid in mainstream production code in a situation where you need to store a reference to an exclusive subobject for later use - eg in a causeEvent. As exclusive subobject references can only be held in local variables or parameters, a technique sometimes used is to store the string of the OID, and then later use String::asOid to get the reference back to the object in question in order to, for example, perform a causeEvent to have notification fired to the appropriate interested parties in that process. You may, for example, be using this technique on a notification manager class. In this situation, any form of AGC would cause such generic code to break.

Hope that helps,
Pat.

by Patwos >> Tue, 5 Jul 2005 1:17:49 GMT

On thinking about this some more, I've realised that in my notification manager strategy, where I use asOid to get back an object reference for an exclusive collection, in all cases these are persistent objects and would not therefore be affected by any AGC facility - but the potential is still there for the exclusive collection to have been transient.

Pat.

by Patwos >> Mon, 27 Jun 2005 3:18:32 GMT

"As leakage invariably occurs in exception situations, problems end up in production systems ... so kiss goodbye to high availability until the problem is identified"

Unless your transients are leaking in code that is extremely frequently executed, thereby creating millions of transients in short time periods, I'm not sure why this necessarily means kiss goodbye to high availability? Sure, you may end up with a large TransientDb as these leaked objects are overlayed to disk to make room for new transients, but that doesn't in itself mean that you can't maintain high-availability - unless of course you are short on disk where your TransientDb is located?

The transients will be AGC when the process that created them terminates, so in an AppServer situation as/when thin clients disconnect any transients created by that thin client will be cleaned up. This of course doesn't help much with transients created inside ServerApplications that are never shut down but assuming you have a way of bouncing these independent of boucing the entire environment again this can clean up transients created by those processes.

Hope that helps,
Pat.

by allistar >> Mon, 27 Jun 2005 8:30:37 GMT

On top of this, having exceptions raised shouldn't in itself lead to more transient leakage. As long as all created transients are deleted in the epilog of the method that created them, even in cases where exceptions are raised the transient would still be deleted.

Allistar.

--
------------------------------------------------------------------
Allistar Melville
Software Developer, Analyst allistar@silvermoon.co.nz
Auckland, NEW ZEALAND

Silvermoon Software
Specialising in JADE development and consulting
Visit us at: http://www.silvermoon.co.nz
*NEW* Simple web access to Jade at: www.silvermoon.co.nz/jhp.html ------------------------------------------------------------------