Hi Kathy, I have a question pertaining to your solution to the "Sharpen your Pencil" exercise on page 205. You say that a transient variable that is non-null is fine for passivation but the values are not guaranteed to be reset to defaults during activation. Then you go on to say that you should therefore assign null to these variables before passivating. What advantage would this have? Wouldn't you still have the problem of not getting default values upon activation. Shouldn't you, as you stated on page 205, be concerned with reseting transient variables in ejbActivate? Is there really any purpose to assining null before passivation? Keith Rosenfield SCJP SCWCD
Hi Keith, I agree with you. Kathy's comment looks weird to me too, even if my answers to that "Sharpen your Pencil" were correct. I don't see any advantage in setting a transient variable to null in ejbPassivate() because I don't see how it would help you to restore the value at activation time. Best, Phil.
Yeah, this is a little strange. One of the reasons we have this in here is because a lot of people believe (incorrectly) that 'transient' does not work or should not be used with stateful session beans, for passivation. So we wanted to see if you understood that transient WILL work for passivation, even if you don't set the value to null. So, it sounds like your question is, "Why would you bother setting it to null if it's just going to be reset during activation?" Well, you don't *need* to if you are absolutely certain that you are going to re-establish the value in ejbActivate(), but it is still considered good practice as more of a safety precaution. If you set the value to null, then there's no chance, for example, that you'll have other code that later checks for a non-null value and thinks all is well... You might, for example, decide that it's a waste to re-establish the values in ejbActivate(), because you only need them sometimes... so you might wait before re-establishing the value of that transient variable. In that case, you again might have a scenario in which you check for a non-null value and... I know, I know, this is a little bit of a stretch... since it isn't likely that you'd do this, but that's why setting it to null is considered a good safety practice. You probably don't *need* to, but it's a good safe habit, and reinforces the notion that passivation isn't EXACTLY serialization, although it *might* be and though it behaves (with the exception of 'transient') as thought it is serialization. I'm glad you pointed out that I used a strange explanation, though. I'll have to work on that for next time around... cheers, Kathy
Oh... I see the problem. No, it's actually not worded in the spec that a null transient variable is *guaranteed* to come back as null (which is why this issue is NOT part of the exam), but it's almost inconceivable that it would not be. In other words, the problem with using 'transient' is NOT about what will happen to a transient null value, it is about what would happen to something marked transient which is NOT null, if in fact the Container is not using Serialization. In that case, the 'transient' variable would not necessarily be respected, and the non-null, non-serializable thing -- despite being marked transient -- will not be reassigned a default value. No, the Container that is not using serialization will simply try to restore it to whatever it was at the time of passivation. And for a non-Serializable runtime thing like a Socket... well, you get the idea. Bad things could happen. But we believe that a Container will either; * Respect 'transient' and restore a value to its default for that type OR * NOT respect 'transient' and instead attempt to restore ALL values to what they were before they were passivated. So, we believe that a null value, despite being marked transient, will always restore as null. The problem is that a NON-null value, marked transient, will NOT necessarily come back as the default of null, if the Container is not using Serialization and ignores 'transient'. But, I'm using the word "believe", so I reckon I should back off just a little on the reasons I gave earlier for using it as a safety measure. Since it isn't technically worded that way in the spec, that DOES leave the possibility that a null transient variable would come back as something other than null, however remote that possibility is... it still exists, I guess. And in that case, I'd have to agree that you'd probably STILL want to be even safer and just take care of it in ejbActivate(), as you suggested. One more time, though, this is NOT on the exam What IS potentially on the exam is this; * Non-null, non-Serializable variables marked transient CAN be passivated. You just can't guarantee what you'll get back...
* Non-serializable variables marked null can be passivated. (and then of course all of the other rules for things which can be passivated... the way it is defined in the spec). So I guess you asked a good question, and one that I frankly hadn't even thought about for a long time... I just kind of took it for granted since that's the way we always used to do it in my group at Sun (mark it transient AND set it to null). The real question is perhaps why did we bother with transient at all? (since we're already setting these things to their default values, during passivation.) And the answer was really, "just in case the Container IS using Serialization, for passivation or any other scenario" and in that case, using transient we get a *perhaps* slight performance gain from having the variable skipped completely, which it will NOT be, if it is not marked transient. OK, that's probably all my brain is capable of on this one... cheers, Kathy