Cameron Purdy on TheServerSide Symposium

Discussions

News: Cameron Purdy on TheServerSide Symposium

  1. Cameron Purdy on TheServerSide Symposium (60 messages)

    I thought TSS was innovative because we had 'nearly live' day by day Java One coverage, but Cameron Purdy pleasantly put us to shame with awesome LIVE coverage at TheServerSide Symposium conference this weekend. He's typing away everything he sees, connected live via GPRS.

    TSS will also post a show summary withina couple of days, and I expect a lot more blog entries from many people to follow once every one flies back home, but in the mean time, kudos to Cameron for bringing all of this to us!

    Check it out.

    http://blogs.javalobby.org/page/cpurdy/20030630

    Threaded Messages (60)

  2. Ahem...[ Go to top ]

    The "WebSphere Guy in the back of the room" was me, and my comment was that WebSphere Enterprise Edition has implemented Activity sessions (JSR 95, http://jcp.org/en/jsr/detail?id=95) after Bruce Tate said "I don't know of any application server vendors that implement this yet...".

    Kyle
  3. Ahem...[ Go to top ]

    Hi Kyle,

    Heh! I actually meant to post an update on the blog after I met you, since you're one of the WebSphere crew that I've been meaning to meet (put a face with the name) for some time ... particularly from your JavaRanch posts. At any rate, this is definitely a good conference for meeting a lot of people that I've conversed with "virtually" for a long time.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  4. No problem :)[ Go to top ]

    It was good to meet you too Cameron. I'll agree, the Serverside conference was a great experience in that since it was smaller than JavaOne or many other conferences that you had a better chance of actually meeting people you only had met "virtually". Sorry we never got the chance to talk more about Coherence.

    Thanks.

    Kyle
  5. Cameron, thanks for the invalueble service to the J2EE community. I kinda expected you would do daily recaps of the sessions but never expected a "live" coverage.

    Just curious, is there any public or private talk on the PetStore vs. PetShop rematch? After all a)this symposium is organized by TSS (I know they did not actaully do the benchmarking but they did break the news first to the community), b)TMC seems to have a large presence (include Ed Roman) at the symposium, c)Bruce "Bitter Java/EJB" Tate (he gave prominent description of the TMC benchmarking effort in his EJB book) is there, and d)lots of people are presenting alternatives to EJB's. For some reason I have a feeling TMC has been extremely quite on this, maybe trying to get people to forget about their misguided work, while M$FT is all pumped for another around of battle. Personally, I think a rematch will get part of the lost reputation by TMC back, and set the record straight about J2EE.
  6. It seems that a lot of people in J2EE camp take it as granted that J2EE is faster than .NET. In my personal experience, JVM and .NET are very similar performance wise. I would expect that .NET would match J2EE in scalability and performance, if the benchmarking is done properly. Again, it's just my thought.

    What we have is the results of the benchmark, where .NET won. We can not blame only the programmers who wrote the J2EE part. The results could be an indication of the real issue: growing number of Java APIs and questionable "patterns"/practices for every set of APIs.

    It shouldn't take a collective wisdom of thousands of best Java experts to write reasonably fast implementation of dumb petstore example. Clearly, there's a problem.
  7. It seems that a lot of people in J2EE camp take it as granted that J2EE is faster than .NET.


    Rolf, is that you? :-)
  8. Not, really :)[ Go to top ]

    I didn't visit this site since last summer. It's just I had a chance to work with .NET this year, so my perception of it evolved :)
  9. Is is me, or did no one ring this bell in this thread?
    There I was.. following a nice debate about Entity Beans and book advice... and someone has to go and drag up the ".Net vs. J2EE" thing again. Please do try to pay attention.

      BTW, I want to be Floyd when I grow up.
  10. Great coverage for those of us who couldn't make it. I especially like your humorous touch. Thanks for taking the time to write it up, we appreciate it.

    Michael
  11. "Ted Farrell kicked off the conference this morning with an introduction to Oracle developer tools ... marketing. Oracle has decided that metadata is a better way to express information about design than code. They're right; it's just too bad it took them ten years to figure out why VB was better than C++."

    In a different session, a speaker:
    "suggested avoiding TopLink because Oracle has a vested interest in keeping it a proprietary non-standards-based product."

    "He also mentions TopLink (now Oracle -- which is why he says not to use it). "

    Yep, those were, definitively, the most important things said about Oracle...Gee

    I didn´t attend myself the conference, but I had quite a few references and analysis more in depth than that, don´t let your Tangosol side darken you Cameron...Does really toplink scare you that much?:-)

    Gee...
  12. Hi Kara,

    I'm no journalist, and my comments weren't intended to be 100% objective. Please don't hold me to too high of a standard. The keynotes were all marketing though (you couldn't eat without being marketed to ;-) and I did think that while Oracle was on the right track with tools by looking more at metadata (as you'll see I made similar comments about John Crupi's presentation). However, while Java may have most of the best tools in the market today, we haven't moved that far beyond the way developers used MFC in 1995 (IMHO). And in some ways, we've moved backwards from what you could do with VB in 1993.

    On the TopLink comments, I may or may not agree with what was said, but I was trying to post it as it was presented in the sessions. You can verify that with anyone who his sessions (Bruce Tate). He mentioned what I wrote about TopLink at least 6-7 times in two different sessions, and I only wrote it down twice ;-). Regarding my own view of Toplink, some of our customers use it extensively, and two of our partners compete against it, but I have nothing to gain from bashing it myself. Honest.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  13. Hi there Cameron,

    In fact, I really think that we have gone way further than MFC, over all cause JAVA tools nowadays allow you to accomplish the building of systems that are quite more distributable, portable and scalable than those you could build with MFC. It migth be truth that GUI development has really gone slowly in java, but also, for those of us that started programming with Visual Cafe, the state of the art of java IDE´s is so much more powerful as compared to 1996´s and 1997´s.

    As for the Toplink comments, i realy believe that someone as "emotional" as you would have shared some personal points of view about Toplink if you had disagreed with Bruce Tate (:-)). It is quite funny to consider Toplink bad cause it is "now Oracle". I also sounds funny recommending to "avoid TopLink because Oracle has a vested interest in keeping it a proprietary non-standards-based product". Gee, i have used toplink for years, and it is as propietary as it used to be (when Toplink was BEA´s favorite persistence framework, nobody would complain so much about its propietarity: http://e-docs.bea.com/wls/docs60/programming/environment.html).

    It is just that it hurts to see how a product becomes "bad" based on who is behind it. We have been hearing so much good stuff about Toplink for years and it all has stopped as soon as Oracle has bougth it (and that scares us, as toplink customers :-))

    Also, toplink is even far more standard than it was before since it allows you to be plugged as persistence framework in more and more J2EE servers and architectures every day...so...You are going to scare us, and make us think that we can get more vendor locked with Toplink/Oracle that we can with Coherence/Tangosol or so :-)

    I also vote for peace, but mainly for objectiveness (either your "comments weren't intended to be 100% objective" or "you were trying to post it as it was presented in the sessions". Not both :-)

    Good work, however, it makes us keep and eye on tech evolution.:-)
    Cheers
  14. Kara,

    I think you're right! It is a conspiracy. A dark and evil conspiracy. Cameron and Tangosol are trying to bring down Oracle, the worlds second largest software company.

    And if you ask me, its working!

    I think you need to relax a little Kara. Noones out to get anyone here. As far as I can tell, you seem more "emotional" than Carmeron.

    Jason McKerr
    Northwest Alliance for Computational Science and Engineering.
  15. Sure sure...i know there´s no conspiracy Jason, i am just a customer that is getting scared by Cameron postings and that, after some calm, relaxed and in depth analysis have found little meaning on his coments :-)

    And yes, i very emotianl, but also MORE OBJECTIVE :-)

    Cheers and peace, over all peace...
  16. Am I alone in thinking...[ Go to top ]

    Bought the bitter EJB (Bruce Tate and et all including JDO camp) book last week while traveling between Ireland and Holland. It only took a 1/2 a day to get through the book.

    Maybe I expect too much from Java books that I pay for but how come I feel that during the reading of such books that they will only last a week on my bookshelf before I dump them on someone (who has too much time on his hands).

    I don't want to hijack this thread as it refers to Cameron's excellent 'unpaid' work but I had hoped that he would have at least questioned many of the points raised during the conference in terms of accuracy/validity/relevance, especially when the topic is about "EJB sucks, blah, blah....".

    Is it too much to ask for hard evidence (from the experts) that at least attempts to quantify 'lack of scalability'. The whole book could be easily sumarised into a few pages basically stating "we THINK there is a performance problem with EJB, especially CMP, and yes STATE is bad IT DOES NOT SCALE, lets get that out of the way " - after it was stated about 10 times already, ;-(.

    A example of a book that tries not to insult the intelligence of the reader is "Database Tuning: Principle, Experiments, and Troubleshooting Techniques". There provide measurements across databases and platforms. Maybe someone can do this for BEA, IBM, Borland, Sun and Oracle. The only problem in the J2EE world is that before the book is out its out-dated.


    William Louth
    JDBInsight Product Architect
    www.jinspired.com
  17. Am I alone in thinking...[ Go to top ]

    Yeah, returning the second bitter book I bought to the seller :-(
  18. Am I alone in thinking...[ Go to top ]

    Yeah, returning the second bitter book I bought to the seller :-(


    Really? What didn't you guys like about it?
  19. Am I alone in thinking...[ Go to top ]

    I appreciate the hard work you guys put in for the book, but,

    I found the personal anecdotes distracting (like in the original Bitter book). But this is not the major issue. The major problem is that the book lacks meat/substance as William pointed out. For people who spend at least an hour a day reading posts @ TSS, the topics covered in the book are obvious but the solutions/conclusions are shallow in many places. Also, the repetitive/verbose way (again pointed out by William) the book uses to drive home most of the anti-patterns makes my mind drift...
  20. Am I alone in thinking...[ Go to top ]

    William,

    > Bought the bitter EJB (Bruce Tate and et all including JDO camp) book last week while traveling between Ireland and Holland. It only took a 1/2 a day to get through the book.

    > Is it too much to ask for hard evidence (from the experts) that at least attempts to quantify 'lack of scalability'. The whole book could be easily sumarised into a few pages basically stating "we THINK there is a performance problem with EJB, especially CMP, and yes STATE is bad IT DOES NOT SCALE, lets get that out of the way " - after it was stated about 10 times already, ;-(.

    I don't believe this is a fair assessment in the least, and I'm questioning how much of the book you actually read. I myself am an avid reader and have admittedly been disappointed by the lack of new/unique material in Java books as of late. I tried to break this trend, and based on the feedback we've had so far, I'm confident we succeeded.

    I know for a fact that all three of my coauthors contributed fabulous material. I personally made it a point to target implementation antipatterns that I couldn't find well documented anywhere else (other books, the net, papers, etc.). I focused on implementation mistakes that occur as a result of misunderstanding design patterns. I see these problems every day. Some of the topics I covered were:

    * Strong separation of remote and local interfaces and how it affects maintainability and performance.
    * Exception handling strategies, specifically avoiding white noise in your logs and maintaining stack traces without working too hard.
    * Lazy loading domain objects. This is huge. If you have two or more clients, DTOs are the biggest waste of time. The closest I've found to this in another book is where Fowler's PoEAA mentions that you can do it, but not how to go about it. I've actually done more work on this using AOP that I hope to document at some point (perhaps a second edition).
    * Implementing an OO domain model despite EJB (or any remote interface for that matter). Too many people think that session beans are for business logic and that entity beans should be relegated to data holders. It's exactly the opposite. This may be obvious to you, but I have yet to find a project with a truly OO domain model.
    * Threading and making your application more resilient to hung resources and troublesome services. I've run into this problem countless times--hung database connections or long running operations monopolizing the server's thread pool and dragging the entire application to its knees.
    * Page by page iterator implementations. I have *never* been able to find good resources on this, and I run into the problem time and time again. I did performance testing for this section that led to some pretty surprising results. IMHO, the Core J2EE Patterns actually give bad advice when it comes to this subject.
    * Interoperability. IIOP's great, but what if you have a 1.2 VM in the mix (often the case with applets). Why go through the hassle of Web Services? Serialization is so much more powerful (you can pass DPs, etc.). _Bitter EJB_ addresses all of these concerns and more in addition to introducing the concept of a binary web service (get the best of both worlds, web services and RMI, when you have Java on both ends).

    You know what? That's just chapters 3 and 4. I could go on, but first I'd like to ask what part of "we THINK there is a performance problem with EJB, especially CMP, and yes STATE is bad IT DOES NOT SCALE, lets get that out of the way" encompasses those topics?

    Thanks,
    Bob
  21. Am I alone in thinking...[ Go to top ]

    "I'm questioning how much of the book you actually read"

    Amazing for once in my life I have had someone question me about my lack of reading. My partner is always going on about the amount of reading I do and the number of books I buy. She is always finding my secret storage locations. I buy between 5-10 books each month on various subjects (HCI, Graphic Design, Distributed Systems, Database Systems, Java?....) and always try to read them in full, unless of course they are meant to be used as reference books or I become bitter during the reading, ;-(.

    Bob, I will give you some credit, your chapter was probably the most readable. It did not repeat the same message every paragraph and you did include at least some test results in the page-by-page Iterator example. That said I don't think the content is as strong as you make out but that could be because I have been working with CORBA for many, may years and EJB since Jan 1999. I am sure if you have spent sometime on the EJB Interest that nothing new would be found in your points. I would be suprised if people who have built a J2EE system did not all come across the problems and solved them - in some cases much better. Nothing like "THIS IS HUGE", ;-).

    I am going to reread your 2 chapters again in the meantime could you do the same for the 3 chapters that follow yours and provide a honest critic if thats possible, ;-).


    William Louth
    "Test & Tune with Insight"
    www.jinspired.com
  22. Am I alone in thinking...[ Go to top ]


    > I am going to reread your 2 chapters again in the meantime could
    > you do the same for the 3 chapters that follow yours and provide
    > a honest critic if thats possible, ;-).
    >

    Hi William,

    I wrote the two chapters that follow Bob's sessions chapter, and I'm certainly open to any criticism you may have. Both of those chapters were reviewed publicly here on TSS. I took those reviews very seriously, and I know the chapters are better because of the contributions of TSS reviewers. Of course any errors, omissions, etc. are my fault. So, while I'm open to criticism now, I wish we could have chatted during the review cycle to get your suggestions into the book. We tried our best to listen before letting the ink dry.

    Regards,

    Mike
  23. Am I alone in thinking...[ Go to top ]

    Hi Mike,

    My initial critic related to the constant drum beat - "EJB sucks" that is evident from many of the 'popular' (often to referred to by first names) serverside posters that your book's content reminds me of.

    In light of the fact that you used TheServerSide as a forum for public review and content input, what could we have expected - there are some "fruit cakes" and "extremists" (I am not talking XP here) on this website.

    In general I found your stateful chapters the hardest to read as you kept repeating "state does not scale" in various different styles. Then after saying this more than enough times you repeated yourself

    "You've no doubt heard that they [stateful session beans] don't scale as well as stateless session beans. Indeed, they generally don't. (There, that's out of the way!)." Thank heavens!

    As an architect it is important to know what is meant they don't scale - "what typically environment, usage, platform, product....".

    The book lacks detail and real world analysis/experiments. Is what you state (;-) really true for all products. A while back many vendors had poor/naive CMP engines and blamed it all on the specification and encouraged users to create big heavyweight entitybeans. Was the EJB 1.1 to blame? Not entirely, because some vendors such as Borland had good CMP 1.1 products that out performed the more "relevant" and "popular" products.

    Floyd has a good design pattern book (if I recall correctly as it has been passed on) but I always had reservations about it. Why? Because I felt that some of the patterns where derived from failings of implementations. They most likely came from usage of the market leading products and thus had more relevance outside my own little world, ;-(. His recent interview throws further light on this.


    Regards,

    William
  24. "As an architect it is important to know what is meant they don't scale - "what typically environment, usage, platform, product....". "


    Exactly, I find "all" the recent J2EE design books are spinning the same chorus line.

    The absolute statements found in these books are self-destructive and serve to invalidate the authors’ credibility. Perhaps, the publishers should start an "In MY Opinion" series, don't get me wrong, I appreciate the incredible hard work that goes into these books. As an architect, I owe it to my customers and peers to constantly challenge my expertise and experiences. Reading these J2EE design books is a great way to stimulate thinking.

    However, when I spot "never", "don't", "always", "EJB too heavyweight" and other similar statements - my thinking process performs a GC...

    I just received my new Core J2EE book yesterday and was nice to see the "composite entitybean" pattern for EJB 2.0. Although, Floyd's pattern book explains the "composite entitybean" should not be used anymore. I used the "composite entitybean" pattern to realize my domain model for EJB 2.0 and it works great for "my project". Although, I did used a "composite entitybean" like pattern before J2EE - thinking... thinking... thinking...
  25. <george>
    when I spot "never", "don't", "always", "EJB too heavyweight" and other similar statements - my thinking process performs a GC...
    </george>

    "Never", "don't" and "always" may be a bit categorical. I try to avoid them, anyway. But it appears that Sun disagrees with you regarding "EJB too heavyweight." Have you seen the EJB 3.0 JSR? Its prime aim is to reduce complexity. And why is criticism of EJB a candidate for "GC"? Is it a sacred cow? Obviously you know better than all those misguided authors and TSS posters, and it seems you also know better than the EJB 3.0 JSR.

    Regards,
    Rod
  26. Re: I'm I alone thinking...[ Go to top ]

    Exactly, I find "all" the recent J2EE design books are spinning the same chorus line.

    >
    > The absolute statements found in these books are self-destructive and serve to invalidate the authors’ credibility. Perhaps, the publishers should start an "In MY Opinion" series, don't get me wrong, I appreciate the incredible hard work that goes into these books. As an architect, I owe it to my customers and peers to constantly challenge my expertise and experiences. Reading these J2EE design books is a great way to stimulate thinking.
    >
    > However, when I spot "never", "don't", "always", "EJB too heavyweight" and other similar statements - my thinking process performs a GC...

    May I suggest _Bitter EJB_? It picks up where these other design patterns books left off, avoiding unsubstantiated absolute statements and unproven theories. The fact is that chances are slim that you can simply read up on an enterprise design pattern, implement it, and have it work right out of the gate (sometimes I wonder if the original authors have ever actually used the patterns themselves). Quirks and gotchas with the underlying infrastructure are often to blame.

    We've used these patterns. We've run into problems for which there was no straightforward answer. We've documented these war stories so to speak in _Bitter EJB_ oftentimes presenting solutions you will not find anywhere else. I've looked.

    So far as being able to glean similar information from online forums, you're right. _Bitter EJB_ was largely born out of these (especially TSS). But, who has the time to go on an excavation, filtering out the 90% of noise and bad advice, each time they come across one of these problems? _Bitter EJB_ documents 90+% of the problems you will run into when using EJBs in one place in a clear, concise manner. Here's a commonly reoccurring problem, here's the options for solutions, here's when you should apply each one.
  27. Am I alone in thinking...[ Go to top ]

    William,

    Thanks for sharing some concrete criticism.

    >
    > In general I found your stateful chapters the hardest to read as you
    > kept repeating "state does not scale" in various different styles.
    > Then after saying this more than enough times you repeated yourself
    >
    > "You've no doubt heard that they [stateful session beans] don't scale
    > as well as stateless session beans. Indeed, they generally don't.
    > (There, that's out of the way!)." Thank heavens!
    >

    I'm sorry you thought I was ranting, but clearly the message hasn't been heard before so I said it a few times, in case people were sleeping the first time. It seemed to have worked. :-)

    The quote you mention -- where I finally stop beating the state drum -- is found on the top of the 9th page of the chapter. Those first 9 pages include an adventure story, an introduction, and a rather lengthy definition of session state, including how it can be valuable and how it can be a burden. The chapter is 30 pages in length.

    So, for roughly one third of the chapter I chose to focus (rant) on the issue of stateful vs. stateless services. It was a concious choice born out of repeatedly noticing that this decision is often times not made early enough. Rather, all too often the first decision is along the lines of whether to use HttpSession or stateful session beans to manage session state.

    My intent was to help the reader avoid potential pitfalls with session state by sharing what I believe to be the pivotal first question: Where is session state beneficial in our application, if at all? The rest of the chapter then discusses ways to use (and misuse) tools for managing session state.

    I wouldn't change much about the chapter. Unfortunately, it didn't work for you. I'm interested to hear responses from others out there (the "fruitcakes" and "extremists"). ;-)
          
    >
    > As an architect it is important to know what is meant they don't scale
    > - "what typically environment, usage, platform, product....".
    >

    I'm very careful to avoid pronouncements that stateful session beans don't scale as compared to other state management solutions (e.g. HttpSession). Indeed, this is very much dependent on a number of factors. If I tried to describe every possible scenario, I'd surely fall short.

    However, I pull no punches in comparing stateful services to their stateless equivalent in general. That is, session state has limiting factors to scalability, namely memory. Session state is something I'm willing to live with if I need it, but it should be the exception rather than the rule.

    >
    > The book lacks detail and real world analysis/experiments. Is what
    > you state (;-) really true for all products.
    >

    It's always difficult to make generalizations about technology, and I try to avoid it as much as possible. There will always be products that really shine, and others with barely a dim glow at best. If we were to publish experiments from multiple products, for how long would the results be accurate? At what point are we shamelessly plugging products?

    With respect to session state, I chose not to compare and contrast products. Surely some will scale better than others. Instead, I tried to give the reader a guidebook for chosing when and where to manage session state based on general advantages and disadvantages of each approach. Then in chapter 9 I shared a performance testing methodology that I've found useful in really measuring what's true for any specific configuration.

    Again, thanks for sharing your opinion.

    Mike
  28. Great chapter[ Go to top ]

    By the way, I've heard from three different sources that this is hands down the best treatment of stateful session beans to be found, anywhere.

    Great chapter, Mike.
  29. Am I alone in thinking...[ Go to top ]

    William,

    >That said I don't think the content is as strong as you make out but that could be because I have been working with CORBA for many, may years and EJB since Jan 1999. I am sure if you have spent sometime on the EJB Interest that nothing new would be found in your points.

    You're absolutely right. When it comes to EJB developers, you're also very much in the minority (based on my experiences as a consultant), and are thus not the target audience for this book. On the same note, I'm sure you found most of the patterns in Fowler's PoEAA to be rudimentary and obvious, but it's still a bang up book. I pretty much follow and participate on almost all of the lists on a daily basis, including EJB Interest, some vendor newsgroups, patterns discussions, etc., and I can say that much of the content in _Bitter EJB_ goes well beyond in quality and quantity.

    In regard to the remaining chapters, I'm intimately familiar with the book in its entirety. We collaborated heavily on ideas and reviewed each others' work throughout the entire process. Mike did an excellent job addressing the state issue. I personally think that the big problem is that developers know statelessness is good, but they don't know how to achieve it. Just dropping things in the session is so convenient and straightforward, and it's also what I see every day. That's the audience for _Bitter EJB_.

    I learned a lot from the messaging chapter (and I was in the middle of putting together a class on JMS at the time I read it!). In regard to the persistence portion of the book, I do wish we could have gotten more in depth, but there's only so much time and so many pages to spend on one topic. You could easily publish a tome on Java persistence. There's no right answer (or even a slightly better one). I've used JDO. I've used OS frameworks. I'm using entity beans right now. They all have their benefits and drawbacks, and I think _Bitter EJB_ does a great job of presenting each approach in an objective manner. So long as developers aren't still trying to use straight JDBC, I'm happy.

    All of that aside, I'm a book whore as well. The reality is that we're going to be hard pressed to find a book that lives up to our standards. I've personally gone back to Knuth lately (you might know he has a lot of collections of papers out there that are fun reads), but mostly I've been blog and spec. reading.

    BTW, congrats. I noticed JDBInsight is up in the JDJ polls.

    Bob
  30. Am I alone in thinking...[ Go to top ]

    I am looking forward to the publication of the following messaging/eai patterns:- http://www.enterpriseintegrationpatterns.com/toc.html


    <bob>
    "personally think that the big problem is that developers know statelessness is good, but they don't know how to achieve it."
    </bob>

    I believe that if common sense prevailed that most of the antipatterns detailed in various books would become irrelevant. Why is it not so? Developers have their own personal agenda?

    I use state when its appropriate and feels right. I try not to call myself an architect but a designer - whether its designing an user interface, interaction style, user experience, graphic chart, component system, framework, database, or mere Java code. Unforturnately being a 'designer' does not help your career or financial status so I stick to 'architect', ;-).

    EJB has allowed mere mortals (such as myself) to build distributed systems for the general business. EJB has dumbed down many things so that all can attempt to undertake greater challenges with some degree of success and with much less risk than CORBA. But what has not changed is - YOU STILL NEED TO DESIGN.

    <bob>
    "do wish we could have gotten more in depth"
    </bob>

    Me too.

    Bob, I think that CMP 1.1/CMP 2.0 has a whole book in itself. Spend a little time on each vendor's ejb-cmp newsgroup and you would be very suprised to see the hacks, sorry patterns, that are required to get things to work and perform acceptable. CMP 2.0 is not so bad as others are protraying - if good design prevails, a good persistence engine is used and configured correctly. EntityBeans and CMP 2.0 engines are not going to die off anytime soon. I have learned from working in Borland that having a perceived 20-30% better appserver solution is not enough to change the market. Good enough and in time seems to be the norm, ;-(.

    JDJ votes? It amazes me the number of votes but my friends say why should it "JDBInsight 2.0 is a great product and makes Java/Swing look great". I will wait and see. Maybe I was wrong - great products do have their day.


    Regards,

    William Louth
    "Test & Tune with Insight"
    www.jinspired.com
  31. Am I alone in thinking...[ Go to top ]

    <william>I believe that if common sense prevailed that most of the antipatterns detailed in various books would become irrelevant. Why is it not so? Developers have their own personal agenda?</william>

    If only that were true. Case in point, the Page by Page Iterator (or Value List Iterator depending on what patterns camp you hail from). It seems like common sense to me to use a scrollable resultset to implement this: run the query, scroll to the page you need, pull out the records. Yeah right. "Caching resultset" more like. That's quite possibly the worst solution, exactly on par with running the query and iterating to the desired record. Meanwhile, there's little documentation (vendor docs, web sites, books) to suggest that this might even be an issue.

    State is completely a mixed bag. There's no common sense right answer many times. Here's an example. I have to implement a wizard (a form that spans multiple pages) in my web application. As a new EJB developer, common sense tells me to store all of the values from the form in the session, updating it from page to page until the final page where I pull it out and process it. Nope. As easy as this makes the development, you have a number of issues:

    1. Memory usage. You're holding this information in memory for each user quite possibly until the session times out.
    2. Failover, load balancing. Unless you replicate your session to another server after each and every request, your user will be stuck on the same server for the entire session and will lose their work in the event of a server failure.
    3. Concurrency. What if the user has two windows open with the same form? From a usability standpoint, It should be equivalent to having two form sessions, however we can't pull this off with the current infrastructure.

    Do you store the inter-page state in the database? This can help with #1 and #2, but you still have #3. What are we left with? You store all of the values for all of the pages in hidden fields on each and every page in the wizard. That doesn't strike me as common sense, nor the first solution a starting enterprise developer would consider.

    Bob
  32. State[ Go to top ]

    Not to mention that if you do store it in hidden fields, you've just opened a potential security hole. Incidentally, this is what I think entity beans can be used for (being stateful persistable components, even cached now and then) to some extent, instead of pretending to be persistable domain objects.
    BTW, can you elaborate on what you meant when you said "Too many people think that session beans are for business logic and that entity beans should be relegated to data holders. It's exactly the opposite"
    Regards,
    Vlad
  33. State[ Go to top ]

    <vlad>Not to mention that if you do store it in hidden fields, you've just opened a potential security hole. Incidentally, this is what I think entity beans can be used for (being stateful persistable components, even cached now and then) to some extent, instead of pretending to be persistable domain objects.</vlad>

    No more or less secure actually. Using entity beans is equivalent to the second solution I mentioned (database) and fails to meet the 3rd requirement (concurrency). Here's an example. Say your editing two entries in your blog at the same time in two different browser windows. If you store the entry on the session (or in a database) you run the risk of one entry overwriting the other. Unfortunately, from the server perspective, you have no good way of differentiating one window from the other (or even knowing that there are two windows). You could partially overcome this by creating a unique token when the user clicks the "add entry" button and then passing this from request to request, referencing the data in the session or database with the unique token, but what happens when the user clicks "add entry" and then "ctrl+N" to open a new window? Now you have two editor windows with the same _unique_ token being passed from request to request.

    <vlad>BTW, can you elaborate on what you meant when you said "Too many people think that session beans are for business logic and that entity beans should be relegated to data holders. It's exactly the opposite"<vlad>

    Yes, most designs I see are transaction-oriented. The programmer starts with the session bean and goes straight down to the database (or entity beans). All of the logic is in the session methods. Very procedural. A more ideal approach is to have an OO domain model (more code reuse, cleaner, shorter methods, more flexible). You may move the logic to your entity beans and use them as domain objects, but then you don't have polymorphism. I personally wrap my entity beans with my domain objects, using the entity beans as simply data holders. This lets me have polymorphism, i.e. multiple domain objects of different subtypes can wrap the same entity bean type. Then when I get the results from the finder, I wrap the entity beans with the proper domain object type based off of some type field (comparable to the way JDO, etc. pulls it off).
  34. State[ Go to top ]

    Oh yeah, the session beans simply use the facade pattern. My session beans only contain logic to map my OO domain model to the DTOs and no more. The facade and DTOs are simply a performance enhancement and should be abstracted as far away from your business logic as possible.
  35. State[ Go to top ]

    Re security:
    if you keep it in hidden fields, a smart user can submit a URL directly bypassing any validation you do in the wizard part of your code.
    Of course, this just means you have to validate _every_ action submitted, not just as you build your request with the wizard (I'd still do that to give feedback to the user). Keeping your state somewhere else means the state is "safe(r)". I've seen a few applications where this would allow the user to do a really bad things if they knew how. I didn't say it's a sure hole, just a potential if the developers don't realize this and assume everyone will use their application as intended.
    Re entity beans:
    True, it's not ideal. On the other hand it allows you to survive crashes and/or allows the user to go away and then continue with the request few days later. Re-submitting the same key can be dealt with "Do you want to start another request?" question and if so, creating a new one with the data copied from the old one.
    But then, this is just theoretizing as we have no real world scenario so we can't say what (if anything : ))fits the requirements best.

    Re session & entity beans use. Ah, I got confused by your use of word "opposite" :). I was wondering why would you want to use session beans as data holders :)).
    I agree that for a lot of people use of facade means just shoveling all the business functionality on the facade. Ugh. Is ok if your application is very simple (because it's simple to do and simple to refactor later on), but for anything complex leads to 100k classes I dislike intensly.
    Regards,
    Vlad
  36. State[ Go to top ]

    <vlad>Ah, I got confused by your use of word "opposite" :). I was wondering why would you want to use session beans as data holders</vlad>

    Oops.
  37. Am I alone in thinking...[ Go to top ]

    <bob>
    Case in point, the Page by Page Iterator (or Value List Iterator depending on what patterns camp you hail from). It seems like common sense to me to use a scrollable resultset to implement this: run the query, scroll to the page you need, pull out the records. Yeah right. "Caching resultset" more like. That's quite possibly the worst solution, exactly on par with running the query and iterating to the desired record. Meanwhile, there's little documentation (vendor docs, web sites, books) to suggest that this might even be an issue.
    </bob>

    Sorry Bob, but I would not have even considered your 'common sense' case common.

    You know, when I hear such technical requirements I always question the user requirement. Newbies to EJB tend to post questions such as "How can I transfer 5,000 records to my client (web | swing) very, very fast?". This is followed up be endless posts regarding technical solutions (Page-by-Page-Iterator). Rarely does the light go and a poster responds by saying "by only sending the ones the user wants". Common sense !!!

    Now allow me to elaborate on what I meant by common sense in terms of performance and scalability which tends to get more coverage within J2EE/EJB books these days than any of the other enterprise engineering 'ilities".

    ===================================================
    1. Assess Risk (Identify)
    2. Identify Critical Use Cases and Paths (Summarize)
    3. Establish goals/objectives and workloads (Specify)
    4. Model executions and resources (Alternatives & Predict)
    5. Evaluate Model (Monitor and Analyse)
    6. Verify Model (Confirm, Tune, and Manage)


    Regarding the state scenario posted I feel this is more about resolving technical issues than applying 'common sense'.

    <bob>
    "1. Memory usage. You're holding this information in memory for each user quite possibly until the session times out."
    </bob>

    What server are we talking about here?

    OK, assuming you have a container that has such a "feature" could you tell me when this will be a problem. Think about user population, active sessions, business transaction rate, think time, response time etc.... See its the rest of the contextual information I am missing in the book and in your example. When does something become a problem? How much of a problem can it be? What alternatives do I have (hardware and software)? What are the typical costs (resources, time)?

    <bob>
    State is completely a mixed bag.
    </bob>

    Thats the whole point - at the end of the day it all depends on...

    Maybe the format and style of the original Bitter Java book did not scale to the enterprise. Not many things do, ;-). A tradeoffs and application context section might have been handy within the anti-pattern definition


    William Louth
    "Test and Tune with Insight"
    www.jinspired.com
  38. Am I alone in thinking...[ Go to top ]

    <william>
    You know, when I hear such technical requirements I always question the user requirement. Newbies to EJB tend to post questions such as "How can I transfer 5,000 records to my client (web | swing) very, very fast?". This is followed up be endless posts regarding technical solutions (Page-by-Page-Iterator). Rarely does the light go and a poster responds by saying "by only sending the ones the user wants". Common sense !!!</william>

    But, how do you retrieve only the records the user wants? The solution is not obvious by any means. This is a problem that developers struggle with all the time. Hell, I struggled with it for a long time. The answers are in _Bitter EJB_.
     
    <william>
    ===================================================
    > 1. Assess Risk (Identify)
    > 2. Identify Critical Use Cases and Paths (Summarize)
    > 3. Establish goals/objectives and workloads (Specify)
    > 4. Model executions and resources (Alternatives & Predict)
    > 5. Evaluate Model (Monitor and Analyse)
    > 6. Verify Model (Confirm, Tune, and Manage)
    </william>

    Now you're getting into project management. _Bitter EJB_ is for EJB developers in the trenches. They're facing a performance problem, they need an answer.

    <william>
    <bob>
    > "1. Memory usage. You're holding this information in memory for each user quite possibly until the session times out."
    > </bob>
    >
    > What server are we talking about here?
    >
    > OK, assuming you have a container that has such a "feature" could you tell me when this will be a problem. Think about user population, active sessions, business transaction rate, think time, response time etc.... See its the rest of the contextual information I am missing in the book and in your example. When does something become a problem? How much of a problem can it be? What alternatives do I have (hardware and software)? What are the typical costs (resources, time)?
    </william>

    _Bitter EJB_ totally gets into this. If your server has 256MB memory, and you store 10MB of data (say we have a bad Page by Page Iterator impl) per user in sessions, you can only support 25 users (some servers will passivate sessions, but many choose not to because it can end up making things worse). That's not 25 users making a request at the same time. That's 25 unique users over a 20 minute period (or whatever you have your session timeout set to). On the other hand, if you implement your Page by Page iterator correctly, keep unnecessary data off the session etc., the same system can easily support 1000s of concurrent users.
     
    <william> Maybe the format and style of the original Bitter Java book did not scale to the enterprise. Not many things do, ;-). A tradeoffs and application context section might have been handy within the anti-pattern definition</william>

    Ummmm, _Bitter EJB_ has this. Specifically, there are tables listing possible solutions and the tradeoffs of each.

    Bob
  39. Am I alone in thinking...[ Go to top ]

    \Bob Lee\
    Now you're getting into project management. _Bitter EJB_ is for EJB developers in the trenches. They're facing a performance problem, they need an answer.
    \Bob Lee\

    Actually, 3-6 should be a developer's bread and butter. They should certainly have clear goals and objectives (for their own work as well as for the project), they certainly need a design _which developers create_ which models what the durn thing is going to down. Hopefully they'll iterate and re-evaluate their designs, and hopefully they'll also measure the results of their actions.

    I've been a developer in the trenches many times, and the times I've been in the worst jams is when I didn't do the above, and was desperately looking for a quick fix to get me out of it.

    \Bob Lee\
    _Bitter EJB_ totally gets into this. If your server has 256MB memory, and you store 10MB of data (say we have a bad Page by Page Iterator impl) per user in sessions, you can only support 25 users (some servers will passivate sessions, but many choose not to because it can end up making things worse). That's not 25 users making a request at the same time. That's 25 unique users over a 20 minute period (or whatever you have your session timeout set to).

    On the other hand, if you implement your Page by Page iterator correctly, keep unnecessary data off the session etc., the same system can easily support 1000s of concurrent users
    \Bob Lee\

    Your app server has only 6MB of overhead? Gimmee gimmee gimee!

    All kidding aside, paging without massive memory overhead is a pretty well-known problem that was solved, oh, about 20 years ago. It's no different under EJB. The same techniques I used in the late-80s using PRO*C and Oracle will work just dandy for EJBs, from a conceptual standpoint. People ran into problems with this sort of thing because, frankly, they used J2EE in (almost) the stupidest manner possible. Just like people who blame J2EE when they have no indexes on their database and no knowledge of SQL.

    Really, if you know the basics of business software development from 1989, you'll have no problems whatsoever using J2EE today. Bitter EJB isn't a bad book, but it's a little sad that the industry needed to relearn the same lessons for a new technology all over again.

        -Mike
  40. Am I alone in thinking...[ Go to top ]

    <mike spille>People ran into problems with this sort of thing because, frankly, they used J2EE in (almost) the stupidest manner possible. Just like people who blame J2EE when they have no indexes on their database and no knowledge of SQL.</mike spille>

    How would you implement a Page-by-Page Iterator?

    Thanks,
    Bob
  41. Am I alone in thinking...[ Go to top ]

    Really, if you know the basics of business software development from 1989, you'll have no problems whatsoever using J2EE today. Bitter EJB isn't a bad book, but it's a little sad that the industry needed to relearn the same lessons for a new technology all over again.

    Not many developers working in the trenches today have experience which dates back that far (one's brain cells die very fast trying to keep up with all these new programming languages/paradigms :-). So I feel books like "Bitter Java/EJB" should have their niche for people who have started their careers more recently. My problem with the book is that it could have been written in a cleaner fashion. The authors could have cut through the chases, presented clear-cut solutions, and substantiated key claims/statements with tangible benchmark numbers.
  42. It won't help[ Go to top ]

    Really, if you know the basics of business software development from 1989, you'll have no problems whatsoever using J2EE today. Bitter EJB isn't a bad book, but it's a little sad that the industry needed to relearn the same lessons for a new technology all over again.


    >Not many developers working in the trenches today have experience which dates back that far (one's brain cells die very fast trying to keep up with all these new programming languages/paradigms :-). So I feel books like "Bitter Java/EJB" should have their niche for people who have started their careers more recently.

    I believe that the developers who do not have experience in design, should NOT design. Books won't help them. Especially, now when we have too many books. Novices read "blueprints", "whitepapers", "best practices", then sit down and design crappy systems. It's a wrong approach. Novices whould work in teams under the supervision of experienced architects. Just like wannabe surgeons in medical schools. Only after few months of work in a team, they should be allowed to design small parts.

    The IT professionals shortage was a huge problem for the industry. It let inexperienced people into enterprise system design. The results are horrible and will make long lasting negative impact on quality and cost of the systems.
  43. Am I alone in thinking...[ Go to top ]

    <bob>But, how do you retrieve only the records the user wants? The solution is not obvious by any means. This is a problem that developers struggle with all the time. Hell, I struggled with it for a long time.</bob>

    You struggle because this is not your expertise but unfortunately it is in general a responsbility placed on you. Its a bit like asking a developer to design a Swing Application. He might know how to construct the visual components and wire events together but that should not give him a license to design the layout and interaction style. Developers tend to jump into the technical details to quick. Maybe task analysis can help here? Work smarter.

    <bob>
    > 1. Assess Risk (Identify)
    > 2. Identify Critical Use Cases and Paths (Summarize)
    > 3. Establish goals/objectives and workloads (Specify)
    > 4. Model executions and resources (Alternatives & Predict)
    > 5. Evaluate Model (Monitor and Analyse)
    > 6. Verify Model (Confirm, Tune, and Manage)

    Now you're getting into project management. _Bitter EJB_ is for EJB developers in the trenches. They're facing a performance problem, they need an answer.
    </bob>

    Sorry Bob, but now you're showing age/experience. What makes this project management? I can do all these steps in my head (built-in appsimulator) apart from the verification, ;-(. You said that you read Knuth then surely you can create your own abstract machine language and runtime in your brain and work true various alternatives - the art is ignoring noise. You first need to find the costs associate with enterprise primitives.

    Oh, I forgot you and the rest of the team are in the "trenches" and I am in.... I don't think we all have to do so much grunt work as you make out unless of course you practice self abuse. Its not sexy enough when you make things look easy - there has to be pain before gain. Now I am showing my age (31).

    <bob>
    _Bitter EJB_ totally gets into this.
    </bob>

    What does it totally get? Totally what? Is this phrase along with "this is huge" a fullstop/pause in American english.

    <bob>
    If your server has 256MB memory, and you store 10MB of data (say we have a bad Page by Page Iterator impl) per user in sessions, you can only support 25 users (some servers will passivate sessions, but many choose not to because it can end up making things worse). That's not 25 users making a request at the same time. That's 25 unique users over a 20 minute period (or whatever you have your session timeout set to). On the other hand, if you implement your Page by Page iterator correctly, keep unnecessary data off the session etc., the same system can easily support 1000s of concurrent users.</bob>

    If I throw enough shit at a wall some will stick. So what. I am not going to try and dicuss the values you just throw out as I am now starting to feel that nothing is going be learned from all of this. You don't get it and most likely will not for the duration of this thread and even longer.

    Maybe you should go off and read "The Practical Performance Analyst" and then you will understand what I am talking about.

    Let me rephrase all my other posts:
    I don't take advice from anybody until I see evidence that substantiates their conclusions and details the assumptions made and operating context. There is always some degree of trust required but what you are asking is simply unprofessional. Is this so alien?

    <bob>Ummmm, _Bitter EJB_ has this. Specifically, there are tables listing possible solutions and the tradeoffs of each</bob>

    I give up, EOT.


    William Louth
    JDBInsight Product Architect
    www.jinspired.com
  44. EJB CAN work, but ..[ Go to top ]

    EJB CAN work, no one is arguing that.

    What people are pointing out that if you do not use EJB, but use JDO or RowSet, or DAO things are faster, cheaper, more scalable, faster REALTIVELY.

    So it's not that you CAN'T get something to work with EJB, the point is that it is easier if you avoid EJB.

    As a software engineer, you seek to reduce costs, increase performance, productivity.
    So EJB's are relative solutions to non EJB solutions.

    .V
  45. Am I alone in thinking...[ Go to top ]

    <william>You struggle because this is not your expertise but unfortunately it is in general a responsbility placed on you. Its a bit like asking a developer to design a Swing Application.</william>

    Application developers shouldn't be expected to understand SQL/JDBC? You're right, this responsibility is placed on developers every day. _Bitter EJB_ outlines some of the traps in a way that can help these developers anticipate them and weigh the respective risks and workloads.

    <william>Sorry Bob, but now you're showing age/experience. What makes this project management? I can do all these steps in my head (built-in appsimulator) apart from the verification, ;-(. You said that you read Knuth then surely you can create your own abstract machine language and runtime in your brain and work true various alternatives - the art is ignoring noise. You first need to find the costs associate with enterprise primitives.</william>

    You're 100% correct, but here's where I'm coming from. Assigned with "pulling only the records the client needs," I rated both the risk and the workload very low. Based on vendor docs and APIs, the solution seemed easy enough. It just so happened that it wasn't, and it bit me. I was stupid and naive, so be it. But, I documented my experiences in the hopes that others won't meet the same pitfall.

    To be more specific, new technologies came out, JDBC 1.2 scrollable resultsets (and this wasn't 1989 BTW ;)), that made it look like I could solve this problem in a simpler, more vendor-independent manner. It just so happened that this wasn't the case--the tool didn't work as advertised.

    <william>Maybe you should go off and read "The Practical Performance Analyst" and then you will understand what I am talking about.</william>

    I certainly will, but I doubt it will advise me to build a system that can only service 25 concurrent users because that meets today's requirements when I can just as easily (no extra cost) build a system that can scale to many times that. _Bitter EJB_ helps developers cultivate the latter mindset.

    <william>I give up, EOT.</william>

    I'm sorry you feel that way.

    Thanks for the enlightening conversation (sincere),
    Bob
  46. So...an EJB entity fan?[ Go to top ]

    We tried to present a fair picture of EJB. I think we accurately reflect the prevailing attitudes of many in the industry. I want to be clear that I fully support several parts of EJB, and did so in my talk: stateless session beans, MDB, and even stateful session beans. Rarely do you see such a positive discussion of stateful session beans.

    We do not like entity beans, and we support those arguments:

    1) EJB CMP is limiting in terms of your model. Other persistence alternatives have much better flexibility. JDO is far superior in terms of transparency.

    2) EJB CMP is a coarse-grained model. Persistence is a fine-grained model. That leads to complexity of implementation with EJB that you just don't have with other persistence models.

    Performance? I didn't say much about performance, beyond the fact that EJB needs to do more work than many other persistence frameworks. The database is usually the bottleneck. (I did, however, rightfully rag on EJB 1.x performance.)

    I think that these ideas are well-supported, common, and fair. Bitter EJB is not an EJB bashing book. We do rightfully point out that there are better persistence alternatives out there.
  47. Thanks for the comments about my talk. In fairness, I did say that Oracle is a great company, and TopLink is a great product. I firmly believe both. I also said that if you're a BEA customer or a DB2 customer, then you should be concerned about the Oracle acquisition. After all, Oracle and BEA/IBM are direct competitors. Oracle has a vested interest in seeing both fail. Oracle, quite simply, has a conflict of interest in this area.

    If I were a pure Oracle shop, or an existing TopLink shop, I'd definitely continue to use both.

    Do you belive that no such conflict of interest exists? What do other customers say?
  48. pictures[ Go to top ]

    http://photos.autenroad.com/album09

    I took a few photos (yes that was me annoying speakers with the flash). A good portion of the indoor pictures didn't turn out due to the fact that my flash is way under powered for the conditions.

    share and enjoy,

    Craig
    Open Source Paparazzi
  49. contribute your pictures.[ Go to top ]

    I opened up my TSS album at the above URL so that other folks can create sub albums and add their own pictures. Have at it!
  50. inappropriate pictures[ Go to top ]

    I apologize for the inappropriate content someone posted to the pics page. Serves me right for trusting folks. If you have any pics to share, feel free to email me (craig_e_pfeifer at hotmail dot com) and we can make arrangements to get them posted.
  51. Thanks for the picts[ Go to top ]

    Even found a picture of me and my buddies :-)

    Jim
  52. Thanks Cameron. I'm not able to attend. (never time nor money) I appreciate the running commentary.
  53. OMG, stop clicking that link!!!

    The freeroller was serversided. ;-))
  54. I printed out the blog to PDF format (400KB) to cut the load on free-roller. Sorry: links etc. don't work on the PDF and the formatting "inhales vigorously".

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  55. Good show, Cameron! Thanks!
  56. My report[ Go to top ]

    I posted my report of the Symposium at http://beust.com/weblog

    freeroller seems to be back but still flaky.

    --
    Cedric
    http://beust.com/weblog
  57. JDO Subqueries and Transactions[ Go to top ]

    Hi Cedric

    Some of you comments on JDO were not quite correct:

    "Contrary to EJB, transactions in JDO are not declarative: you open and commit them in your code."

    This is true in an unmanaged (e.g. non-J2EE environment). In a J2EE environment the JDO runtime will hook up with the transaction manager of the app server. So if you are using JDO in a container managed tx session bean you do not have to do any thing with transactions. When you get a PersistenceManager(PM) from the PersistenceManagerFactory(PMF) it is automatically enlisted in the transaction. If you use bean managed tx then you should use the normal UserTransaction and the same applies. If a J2EE tx is active when you get a PM from the PMF you will get the same PM back for each PMF.getPM() call.

    This fits the JDO philosophy of only dealing with persistence. If you need managed transactions, security etc then use JDO in session beans.

    "As far as I can tell, there is still no support for sub-queries"

    I assume you are talking about SQL subqueries? You can use JDOQL variables to do this:

    class Person { // person table
        private List addrs; // of Address in person_address link table
    }

    class Address { // address table
        private String city;
    }

    To find all the Person's who live in "Cape Town":

    Query q = pm.newQuery(Person.class, "addrs.contains(v) && v.city == p");
    q.declareVariables("Address v");
    q.declareParameters("String p");
    Collection ans = (Collection)q.execute("Cape Town");

    If you run this using JDO Genie against say Sybase we will generate SQL with a subquery joining person_address link table to person to test the city. If you run against MySQL (which does not do subqueries) we will use an outer join and a select distinct instead.

    "properties such as IgnoreCache, Optimistic, NonTransactionalRead, etc... these are very welcome additions (which are currently offered by proprietary extensions in EJB implementations), it is unfortunate that most of these are optional for vendors to implement"

    This is true. However just about all the O/R mapping JDO vendors implement all of the optional features you listed so this is less of a problem then it first appears.

    Thanks for the info Cameron and Cedric. Much appreciated.

    Cheers
    David
    JDO Genie - High Performance JDO for JDBC
  58. FreeRoller is being moved[ Go to top ]

    FYI, you might get a 500 error trying to read the Blog.
     
    "FreeRoller is currently being moved to a new server." (at Javalobby.org)

    http://linuxintegrators.com/hl30/blog/technology/?permalink=Freeroller.html&page=comments

    Jim
  59. Thanks Cameron (I wondered if that was what you were doing typing away...).

    However remember that even someone as special as Cameron can only be in one place at any time, and there were 3-4 parallel sessions. So Cameron has only covered a relatively small part of an amazing conference.

    Thanks Floyd for organizing it (and inviting me to speak, obviously :-)

    I thought the general standard of the talks was excellent, and not only the presenters but the delegates were all pretty smart. This really was much more meaningful than JavaOne. Just don't ask Floyd about "booth babes".

    Rod
  60. freeroller[ Go to top ]

    For some reason, I can't resolve freeroller.net, but http://blogs.javalobby.org/ does work.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  61. freeroller[ Go to top ]

    For some reason, I can't resolve freeroller.net, but http://blogs.javalobby.org/ does work.

    >

    Not any more. At least not for me. :( It did earlier.