Discussions

News: Tech Talks: Jeremy Boynes and Dain Sundstrom on Apache Geronimo

Bookmark and Share Get thread feed

  1. Tech Talks: Jeremy Boynes and Dain Sundstrom on Apache Geronimo (12 messages)

    • Posted by: Dion Almaer
    • Posted on: July 23 2004 17:19 EDT
    TheServerSide has two tech talks on Apache Geronimo. We discuss the aims of Geronimo, the challenges with integrating the various open source projects which make up Geronimo, and then get into the technical guts. Why the GBeans architecture? What surprises were found when implementing the J2EE specifications? What persistence alternatives are there?

    See both Tech Talks on Apache Geronimo.
    Reply to this

    Threaded Messages (12)

  2. Tech Talks: Jeremy Boynes and Dain Sundstrom on Apache Geronimo[ Go to top ]

    "That’s the future of persistence here. Where an application developer can update some EJBs, or update some objects, and then run a JDBC query and see the same data transparently. That’s the key to transparent persistence in this environment. Not try to come up with one framework, which will work great on its own, provide you know how to use it. And that doesn’t work as applications scale up."

    I think it is a very good idea, but as I understand there is no way to implement it (triggers, procedures). Can it be solved by custom JDBC driver implementation ?
    Reply to this Reply to original

  3. Custom JDBC driver[ Go to top ]

    I think it is a very good idea, but as I understand there is no way to implement it (triggers, procedures). Can it be solved by custom JDBC driver implementation ?
    Exactly, you write a jdbc driver that executes directly against your in memory cache. The trick is you must have a query engine in your cache.

    -dain
    Reply to this Reply to original

  4. Custom JDBC driver[ Go to top ]

    Some people would call this an object-oriented database (i.e. snakeoil).
    Reply to this Reply to original

  5. Cache query[ Go to top ]

    Hi Dain,
    The trick is you must have a query engine in your cache.
    Coherence's partitioned cache supports distributed queries, complete with indexing. The query is passed to all nodes participating in the partitioned cache for evaluation against the local data. This allows for predictable scalability in a clustered environment.

    Later,
    Rob Misek
    Tangosol, Inc.
    Coherence: It just works.
    Reply to this Reply to original

  6. Cache query[ Go to top ]

    Coherence's partitioned cache supports distributed queries, complete with indexing. The query is passed to all nodes participating in the partitioned cache for evaluation against the local data. This allows for predictable scalability in a clustered environment.Later,Rob MisekTangosol, Inc.Coherence: It just works.
    This is one of the many reasons why Coherence rocks. I hope to offer an integration for coherence.

    -dain
    Reply to this Reply to original

  7. Cache query[ Go to top ]

    Coherence's partitioned cache supports distributed queries, complete with indexing.
    Is it SQL ?
    Reply to this Reply to original

  8. Cache query[ Go to top ]

    Hi Jouzas,
    Is it SQL ?
    We have a filter API (com.tangosol.util.filter.*) that includes all the standard operators as well as some more advanced filters. This allows you to build a "filter chain" that you can then pass to keySet(...) or entrySet(...).

    We have had some customers write a SQL wrapper using the filter API.

    Later,
    Rob Misek
    Tangosol, Inc.
    Coherence: It just works.
    Reply to this Reply to original

  9. Cache query[ Go to top ]

    As I understand it must be better to
     implemnt JDBC driver without any cache and to fire events from local SQL parser before to transform query to native SQL and before execution. One of callbacks can be a cache implementation.
    Reply to this Reply to original

  10. EJB.not; JDBC[ Go to top ]

    Appropriate that when one talks EJB, we hear use JDBC.

    I wonder if there is something better?
    .V
    Reply to this Reply to original

  11. EJB.not; JDBC[ Go to top ]

    Appropriate that when one talks EJB, we hear use JDBC.I wonder if there is something better?.V
    Probably SQLJ was better. Plain JDBC is too boring and it is very error prone API.
    Reply to this Reply to original

  12. What about AO?[ Go to top ]

    "...So, for our stuff we don’t need AOP, I mean, J2EE doesn’t need something like AOP at all to work... "

    Yeah, but what about AO? Why wasn't this brought up in the interview? I would like to know how the Geronimo team feels about AO...
    Reply to this Reply to original

  13. What about AO?[ Go to top ]

    "...So, for our stuff we don’t need AOP, I mean, J2EE doesn’t need something like AOP at all to work... "Yeah, but what about AO? Why wasn't this brought up in the interview? I would like to know how the Geronimo team feels about AO...
    Isn't that just AOP without the 'P'?
    Reply to this Reply to original