Win a copy of The Business Blockchain this week in the Cloud forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

question on non-transient , non serializable field usage on ejb for part-1

 
suekar meredilko
Ranch Hand
Posts: 153
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
folks,

1) why should i as a ejb developer set non-serializable and non-transient to null. As anyways non-serializable members will not be written to HDD when bean is passivated.

2) Also in one of the notes(chris), I read the following :
"The container must maintain any instance fields that reference objects of these types(e.g. jndi, session context, JTa transaction, remote references) even if they are not serializable"

this is not true. actually these interfaces are implemented by the container vendor api(s) and they will make sure that it is serializable. When the container tries to passivate, it will do so to only instance variables which are non-tranisent and serializable..otherwise its gonna throw an error. Non serializable variables cannot be passivated. The container will throw an error.

have i misunderstood anything here ?

[ May 16, 2006: Message edited by: suekar meredilko ]
[ May 16, 2006: Message edited by: suekar meredilko ]
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by suekar meredilko:
1) why should i as a ejb developer set non-serializable and non-transient to null. As anyways non-serializable members will not be written to HDD when bean is passivated.

Not just for helping the gabage collector but also to avoid "luck behaviour" that in a few situations will no longer follow luck - errors that are hard to find. I.e. you may be lucky in 99% of calls to get the same bean instance again, properly initialized/filled, but this is not guaranteed nor intended.
If you set those members to null on passivation then you detect those errors immediately by getting a NullPointerException in 100% of cases.

Originally posted by suekar meredilko:
"The container must maintain any instance fields that reference objects of these types(e.g. jndi, session context, JTa transaction, remote references) even if they are not serializable".
This is not true. actually these interfaces are implemented by the container vendor api(s) and they will make sure that it is serializable. When the container tries to passivate, it will do so to only instance variables which are non-tranisent and serializable..otherwise its gonna throw an error. Non serializable variables cannot be passivated. The container will throw an error.

I guess you both mean the same thing. The container MUST and WILL try but CAN NOT perform and therefore throws the said exception. But it does not just e.g. ignore anything ...

Note that what you wrote "When the container tries to passivate, it will do so to only instance variables which are non-tranisent and serializable..otherwise its gonna throw an error." is a contradiction within itself: Why should the container throw an exception if it would not try to serialize those "only instance variables which are non-tranisent and serializable"?

Maybe this helps a little bit ...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic