Hello,
Ok it seems the passivation + locking still fight among each other. For
some reason this flew under the radar of the first series of tests, but not
on the second.
In short to complete the benchmarks we did wednesday (will post results
soon) we had to disable the caches. Also I was thinking some more about
"removing" the bean, while it is safe, it can throw developers off (what
happened to my bean???) so the best policy would be to check at deployment
time if the bean is serializable... which is hard if you have no state in...
Anyway the problems with the cache made us remove them for the bench... I am
not sure it is deep, but it needs some more work. Try your hard tests on
the cache and report any problem I will try to make some time this weekend
marc
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Bordet, Simone
|Sent: Thursday, November 23, 2000 2:28 PM
|To: jBoss Development Mailing List (E-mail)
|Subject: [jBoss-Dev] RE: NotSerializableException
|
|
|Hey Marc,
|
|> Yes do remove the bean...
|
|Done in CVS.
|
|> but we were seeing more bugs
|> yesterday under heavy
|> load... we need to work some more on the cache.
|
|Mmhh. I'll repost a comment I've made some times ago regarding the lock
|mechanism, and since I got no answer from you I thought you meant to leave
|things as they are, but maybe it can help to discover bugs.
|BTW, what kind of bugs ? Does it apply to stateful and entity or
|only one of
|them ?
|
|> Basically
|> the benchs would
|> go through with cache and no LRU
|
|? What does this mean ?
|
|Simon
|
|>
|> marc
|>
|>
|> |-----Original Message-----
|> |From: [EMAIL PROTECTED]
|> |[mailto:[EMAIL PROTECTED]]On Behalf Of Bordet, Simone
|> |Sent: Wednesday, November 22, 2000 1:11 AM
|> |To: 'jBoss'
|> |Subject: RE: [jBoss-User] NotSerializableException
|> |
|> |
|> |Hey,
|> |
|> |> |Thank you for the hint. I mixed up the attribute with the
|> |> session context.
|> |> |What I also found appart from the fact that my code was
|> |> wrong is, that in
|> |> |case this type of error arrises, i observed two things:
|> |> |
|> |> |1 - If I made a high number of calls, there came a
|> situation when the
|> |> |server seemed to run in a loop writing the exceptions from my
|> |> |previous message.
|> |> |I only was able to stop him by CTRL-C.
|> |>
|> |>
|> |> mmmmm
|> |>
|> |> one thing we should make sure is that a Passivation that
|> "fails" still
|> |> removes the bean from memory...
|> |>
|> |> it seems they are not removed and they keep on bugging you
|> |>
|> |> flag this is bugzilla for me please
|> |>
|> |> marc
|> |
|> |As it is now, the bean is kept in memory if passivation
|> fails on purpose.
|> |I'm not sure that I want my beans to be removed by the
|> container if they're
|> |not passivatable, since then I have to recreate them loosing
|> their state
|> |(basically for a container activity that may or not happen
|> (passivation) I
|> |would have different behavior for my bean if I remove them
|> when passivation
|> |fails). The spec is not so clear on this (EJB 1.1, 6.4.1)
|> |
|> |"The container may destroy a session bean instance if the
|> instance does not
|> |meet the requirements for
|> |serialization after ejbPassivate."
|> |
|> |We *may* destroy, but IMHO also we may keep it and let the
|> client go on and
|> |finally remove it. The bean implementor can correct the
|> serialization bug
|> |later (because, at the end, this is: a bug from the bean developer).
|> |
|> |Marc, let me know if you want to remove the bean or not,
|> it's a simple
|> |change.
|> |
|> |Bye
|> |
|> |Simon
|> |
|> |
|> |--
|> |--------------------------------------------------------------
|> |To subscribe: [EMAIL PROTECTED]
|> |To unsubscribe: [EMAIL PROTECTED]
|> |Problems?: [EMAIL PROTECTED]
|> |
|> |
|>
|>
|>
|> --
|> --------------------------------------------------------------
|> To subscribe: [EMAIL PROTECTED]
|> To unsubscribe: [EMAIL PROTECTED]
|> Problems?: [EMAIL PROTECTED]
|>
|
|
