Discussions

News: Tales From TSS: The Problems with EJB Persistence

  1. Entity Beans have had a tough time trying to gain acceptance in the J2EE community. In the latest Tales from TheServerSide cartoon, the woes for entity beans continue. Find out why entity bean 'persistence' can prove disastrous for your session facade layer and how 'performance' is even worse outside the container.

    Check out EJB Persistence

    Threaded Messages (23)

  2. very funny :-)

    this one reminds we that TSS thread about J2EE jokes
  3. Enough of this topic[ Go to top ]

    Persistence has been beaten to death. What is this stupid fixation that TSS has with persistence? Almost every alternate article is on persistence. Is there no other problem to solve in the Java world?

    The joke should be:

    session bean says "Get lost, persistence. I've moved on. My new loves are transactions, remoting and security."
  4. Enough of this topic[ Go to top ]

    Persistence has been beaten to death. What is this stupid fixation that TSS has with persistence? Almost every alternate article is on persistence. Is there no other problem to solve in the Java world?The joke should be:session bean says "Get lost, persistence. I've moved on. My new loves are transactions, remoting and security."
    That's because the bottom line for all the new loves - transaction, remoting & security is SECURE AND INTEGRAL PERSISTENT DATAAAAA..................

    Cool down. You know how humor is spelt - H U M O R (or sometimes HUMOUR).
  5. CMR fields are really complex enough to make any use of them. Session bean developers should make use of stored procedures to maximum extent to avoid coding db logic inside the bean. All major databases have equal features in stored procedure languages. Why not use them to maximum and keep your session bean code thin.

    CMP hardly gives any value for all the complexities. Keep the BMP still for very special cases. Most situations session facade will prevail.
  6. Keep the BMP still for very special cases.
    I agree. Never allow your BMPs to move. Always keep them still.

    Or is that "BMP still" as in "whisky still"?
  7. Keep the BMP still for very special cases.
    I agree. Never allow your BMPs to move. Always keep them still.Or is that "BMP still" as in "whisky still"?
    It seems like some people on this forum could do for some "stump juice" - http://www.theserverside.com/news/thread.tss?thread_id=26047#122973
  8. Sorry to do this people[ Go to top ]

    If you are the same Mark who lived on Ealing Road circa 1994 I'd really like to contact you.
  9. Sorry to do this people[ Go to top ]

    If you are the same Mark who lived on Ealing Road circa 1994 I'd really like to contact you.
    Wasn't me. Sorry.
  10. CMR fields are really complex enough to make any use of them. Session bean developers should make use of stored procedures to maximum extent to avoid coding db logic inside the bean. All major databases have equal features in stored procedure languages. Why not use them to maximum and keep your session bean code thin.CMP hardly gives any value for all the complexities. Keep the BMP still for very special cases. Most situations session facade will prevail.
    Ummmm, because stored procedure code is not portable across RDBMSs? 'Kind of silly to develop an application using a platform neutral framework, and then code a significant amount of logic in a proprietary language.
  11. The best one of the cartoons, sweety beans :)
  12. I hate this kind of jokes.[ Go to top ]

    Don't do this anymore!!!!
  13. I agree[ Go to top ]

    Don't do this anymore!!!!
    I agree, I dont mind a cartoon if its actually funny (@see dilbert) but this latest serverside one just made me cringe, I mean "Do you remember me or are you stateless?"! WTF!?!?!

    The "You are persistent!" just about passes as humour, as it is something you might actually hear uttered outside our geeky little world but everything else was just a search and replace job :o\
  14. I don't[ Go to top ]

    I mean "Do you remember me or are you stateless?"! WTF!?!?!
    Dude...Stateless session beans do not *remember* previous session data. Hope you got the joke atleast now.
  15. I don't[ Go to top ]

    I mean "Do you remember me or are you stateless?"! WTF!?!?!
    Dude...Stateless session beans do not *remember* previous session data. Hope you got the joke atleast now.
    Yes, believe it or not, I got the "Joke". It just wasnt funny at all.

    I appreciate humo(u)r is subjective but this just struck me as the kind of Joke a 5 year-old makes up, where the punch is so obvious and far removed from reality that its not longer 'clever'. I tend to find that as I get older I prefer my humour to be a little more subtle and sophisticated than this.

    The "You are persistent" just about works as this is a phrase in the common parlance. However, rarely does someone comment on whether I am stateless or not, so its more of a 'single entendre'.

    Still... if it was amusing for you, then great, but personally I just found it embarassing.
  16. I don't[ Go to top ]

    Don't know about everyone else, but as I read this I heard the voice of Thurston Howell III reading it. :)
  17. W.T.F.[ Go to top ]

    Hey, he got it okay, it's just that it's not funny.

    Can someone please put an end to this column?
  18. Shouldn't that be "Hey baby, do _you_ fancy being my facade layer?"

    Next time I demand to see a message-driven bean.
  19. Yeah!
    Quite funny.

    Shouldn't EJB3.0 drop/depricate entity beans and replace
    persistence with JDO2?
    It could be better, I think for the whole Java community.
    And finally unify specs that on collision course
  20. Where's my royalties...?

    http://theserverside.com/news/thread.tss?thread_id=10955#36779

    ;)

    /Par
  21. Antipattern[ Go to top ]

    Can we see when they get tightly coupled?
  22. Where's my royalties...? http://theserverside.com/news/thread.tss?thread_id=10955#36779;)/Par
    You'll just have to wave this in Floyd's face :-)
  23. C++, VB.NET, C#.Net[ Go to top ]

    Generics were good for C++, so they must be good for Java, right? Wrong! C++ does not have any run time type checking, so casting is essential, whereas Java does.

    In the evil world of .Net, this is a good reason to use VB syntax rather than C# syntax -- the former allows sensible implicit casting, whereas the latter is Java. (VB.Net also allows keyword optional argumets, long overdue from Java. (Implemented properly to allow the default values to change.))
  24. in the end i see the spring mascot winning the day, having just offered to give the session bean a 'hot dependency injection'.

    b