• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Session EJB Quick question

 
Ranch Hand
Posts: 154
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Wonder if someone could give me their opinion on something that puzzles me about stateful and stateless session EJBs

Why did sun make the classification of a stateful/stateless session EJB a deployment issue rather than a class interface classification???

Surely once a session EJB is coded to rely on its stateful nature, i.e reaccessing instance variables during a conversation, this precludes it from ever being deployed again as a stateless session EJB.

I'm asking the question because I have had to check whether an EJB which is currently being deployed as a stateful EJB could be deployed as stateless. Luckily in my case it can but if any methods had relied on the stateful nature I would have been scuppered!

I suppose you could access the sessionContext or something and condition certain logic on the beans deployment.
 
Ranch Hand
Posts: 331
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I had this same question. I agree that it seems very odd since the decision to go stateful vs. stateless clearly invloves programming issues. It sounds like you are lucky that you could easily go from stateful to stateless.

EJB seems to have several cases like this where I ask "why didn't they add another interface. It seems that would make things cleaner." Instead, there are a lot of "generic" interfaces that leave the developer having to remember a long list of rules like "ok I have a XXX bean so even though this ZZZ method is available to me through the interface my bean implements, I can't use it. Of course the compiler will let me, but to quote HF EJB, 'it's just against bean law'"

I suspect that it may be because they needed to maintain backwards compatibility with older versions of the EJB spec?
reply
    Bookmark Topic Watch Topic
  • New Topic