Gemstone offers Facets Distributed Cache integrated with JBoss

Discussions

News: Gemstone offers Facets Distributed Cache integrated with JBoss

  1. Gemstone is offering a free non-commercial download of its Facets 1.1 distributed object cache integrated with the JBoss application server. A free download of Facets for JBoss is available. What do we call them together now? GemBoss?

    "If I had just one wish," Steve Martin once said, "I would wish that all the children of the world would get together and hold hands in peace." Then he went on to add a wish for a million dollars and the "hold hands in peace" thing. And then three wishes, and so on.

    Somewhere high on my list would be that two products like Gemstone and JBoss would get together. Gemstone combines high performance with high security - a valuable commodity these days. JBoss is the ultimate modular Java server.

    See article:
    Dream Team: Gemstone and JBoss by Rich Katz

    Check out Gemstone Facets on JBoss

    Read the press release.

    Threaded Messages (17)

  2. that's near heaven.

  3. Here is an attempt at humor. Inspired by Stu's comment I just couldn't get this song out of my head. I thought I should share a modified version for everyone.

    Heaven - Warrant

    Got the architecture of your app
    And you're doing the same old thing
    It's black and white and Oracle
    And it's looking pretty worn

    See the objects that it has
    Silhouetted in the back
    Their memories are gray,
    That is because they are just a map!

    I don't need to be the king of the world
    As long as I get to persist my objects

    CHORUS:
    Heaven isn't too far away,
    We get closer to it every day.
    No matter what your CTO might say...
  4. CMP: move over?[ Go to top ]


    Hello!

    From my perspective, this technology (transactional
    shared object workspace + J2EE server) is more
    significant than EJB2.0. This technology (from GemStone
    or the competitors) makes clustering soo much easier.
    No more inheritance restrictions for distributed
    objects. Move over, CMP?!?

    But I have to say, I'm a distributed shared memory
    afficionado since the BBN TC2000 :-), so YMMV. I'd
    like to hear (oops, read) your opinion on this
    matter.

    Cheers,
        Henrik
        TNGtech


  5. CMP: move over?[ Go to top ]

    Hi, Henrik and All

    Has anyone compared EJB 2.0 CMP Engine from Webgain(Toplink), ObjectFrontier or other with this GemStone technology (is Facets API pure JDO?). I am interested mostly in performance. As to features I think EJB is poorer but more standart.

    thnx
  6. Hi

    Does anyone know who the pioneering energy trading company were?

    "With a pioneering B2B exchange built on GemStone technology, an on-line energy trading company has become the market leader. Its success is based on the ability to support thousands of traders interacting in complex real-time transactions. Today, the exchange handles $2.5B in transactions per day, a volume that was not possible before GemStone got involved."

    http://www.gemstone.com/products/jboss/high_performance.html

  7. Does anyone know who the pioneering energy trading company were?


    Enron? For the phony trading floor.

    ;-)
  8. No, it wasn't Enron... I think it was one of their competitors...
  9. Well, I'm not sure who it was, but I know for certain it was not Enron.

    -Mark
  10. Since there's a link to ICE (Intercontinental Exchange) on the GemStone home page, I'd guess that's the trading company they're referring to.
  11. ObjectFrontier provides a similar solution through the integration of it's flagship product, FrontierSuite, with JBOSS. It enhances JBOSS capabilities by providing a EJB 2.0 compliant persistence manager with distributed caching capabilities with synchronization.
    In addition, FrontierSuite also provides a powerful development environment for iterative development of J2EE applications.

    Check out
    http://industry.java.sun.com/javanews/stories/story2/0,1072,42845,00.html
  12. Few months ago i took part in an evaluation survey of several J2ee application servers targeted at selecting one which would suite our application needs.
    I was amazed at how lacking most vendors Entity-bean caching facilities were/are.
    It became obvious to us, that hardly any vendor gives a real high-performance solution to a 'read and write strategy' of data using CMP - there were simply to much database access! we thought the ideal solution would be to integrate an 'in-memory' distributed tier between the EJBs and the database.

    Finally, we chose OC4J, mostly because of its ease of use and integration with Oracles Object cache service (which is now called JCache ).

    Transparently integrating distributed object caching under cmp implementation should be the real thing as it comes to performance, so whats holding the vendors back?

    When it comes to choosing an AppServ, most attention goes to web facilities. I feel that there arent many creative solutions to persistency problems which suites real needs - clustered, fast, cmp with minimum db access.

    So i guess this Gemstone Jboss enterprise is something we should all greet, and speak about - maybe other j2ee vendors will follow.

    What do you gize think? Are you have with your CMP engines?

    Yuval.



  13. A couple of comments about Facets vs. other offerings:

    Gemstone's API isn't CMP-based. It is JDO based. Traditionally, back in the Gemstone/J days, it was a proprietary API that is JNDI-based (i.e., you bind the root objects of your object graph to a JNDI-like tree, defining the entry points to your persistent objects. Kind of like how tables are entry points into predefined relations.)

    Gemstone is pretty much like a database toolkit. It gives you some collection classes for efficiently querying through millions of objects, and includes a basic SQL-like query language and indexing mechanism. If these aren't enough (they're pretty basic IMHO), one can always write your own indexing -- which can be biased to the access patterns of your particular application.

    Gemstone doesn't, however, give you much in the way of integrating with an RDBMS -- one would use Cocobase or another O/R tool for that. But on the other hand, you don't necessarily need an RDBMS if you're using Gemstone. If you are using an RDBMS, you can store-and-forward changes to it intermittently for future OLAP or reporting -- this will effectively remove the RDBMS from your operational performance, where everything just comes down to how you use Gemstone's cache.

    TOPLink is a great alternative... It doesn't free you from knowing your RDBMS though. You need to understand the quirks and nuances of your underlying RDBMS, and SQL too... so the real issue with TOPLink is that you have a lot more learning to do with regards to a) database platform issues (i.e. locks, concurrency, etc), b) sql issues (i.e. datatypes, caching mechanisms, etc) and c) toplink issues in general (it's a complex product and the docs don't necessarily tell you the whole story)

    Gemstone requires less up-front learning curve but does require more ingenuity & creativity with coming up with your data model since people are often stuck with relational/SQL myopia.

  14. I'd like to comment about the modeling possibilities with Gemstone, and its JDO features... when you say 'creativity', I'd say object oriented technique. What it really does, in my opinion, is release you from, as you say, the SQL myopia, and lets you do things without being hooked into a relational database design. The upshot of this, is that you no longer need a DBA for your enterprise projects. You can now model and persist all your data with OO techniques. You can solve all your problems with Java guys, and no Oracle guys. If any of you out there have tried this, you'll know how truly powerful this is. There are a number of problems out there you can't solve with an RDBMS and Gemstone opens up the doors to these possibilities.

    Unfortunately most CTO's out there predate this technology and subsequently don't understand it, and never get around to leveraging it to solve any problems... They just aren't aware of what you can do with it. They just accept that RDBMS solutions set the limit on what you can do, despite the fact this isn't true. Perhaps the industry might look a lot different if these guys actually "got it."

    Something Gemstone lets you do is walk complex data networks with very little overhead, which in the RDBMS world, should you try to persist this type of complexity, would result in either highly denormalized designs or absurd amounts of joins. This reduced performance occurs with products like TopLink as well. I've seen a number of project sunk because of that product, let me tell you...

    Its best to either solve problems with a pure relational approach, or a pure object approach. Anything in the middle just gets ugly, no matter what your ancient dinosaur o-r mapping advocates will tell you...
  15. On the issue of "creativity" vs "oo technique". I would generally agree, however even some of the most experienced programmers I know don't have anywhere near the amount of "oo technique" experience to be able to design an entire enterprise systems' object model. It's an unfortunate reality that OO technique often is viewed as "fuzzy UML stuff" by the in-the-trenches programmers. Just a cultural assumption I've had to deal with traditionally... Hence, I refered to it as creativity.

    Now that I've stated my love for Gemstone, I'm going to be devils advocate for a while, because as much as I like the product, I disagree with some of Mark's statements.

     "The upshot of this, is that you no longer need a DBA for your enterprise projects."

    (*cough*, *choke*)

    Production Gemstone instances need a fair amount of TLC.. that's requisite for a DBA to me. This is a major reason behind the failure of OODBMS in the marketplace, the lack of DBA support. OODBMS are such a programmer-biased tool they don't realize the importance of a DBA in maintaining an enterprise system, just like a good sys admin.

    "You can solve all your problems with Java guys, and no Oracle guys. If any of you out there have tried this, you'll know how truly powerful this is. "

    In some sense I agree with this, in that I've experienced the power of the all-object, all-Java solution. But I also disagree in that I've seen the power of what good Oracle DBA's will do to help you out. The whole reason the RDBMS model became popular was to free users from the tyranny of programmers.. that are already pressure to deliver operational features instead of decision support / reporting features that often get swept under the rug.

    With RDBMS we got an intermediate group.. the DBA, report writer, and OLAP cube designers. This divison of labor has some notable benefits....

    "There are a number of problems out there you can't solve with an RDBMS and Gemstone opens up the doors to these possibilities."

    Solutions that require a complex graph of knowledge representation are better served by an OODBMS. The majority of solutions don't fall under this umbrella. Most require a balance between canned and ad hoc data access, and non-programmatic access to the underlying data with graphical tools (DBA tools, report writers, OLAP tools, etc). This is the tradeoff with RDBMS vs. ODBMS... you get more freedom with an ODBMS but no support or ties to the rest of the world beyond what you write yourself. For programmers this is fine, for managers and users, this isn't.


    "This reduced performance occurs with products like TopLink as well. I've seen a number of project sunk because of that product, let me tell you..."

    Not in my experience. This seems to be a lot like a "blame the tools" approach, and not looking at a potentially over-complicated object model or relational model. Some domains are definitely very complex (CAD/CAM, manufacturing, utility billing, etc) and would be better served by an ODBMS. But I wouldn't diss a good product like TOPLink because it can't handle a portion of projects when it could definitely handle the majority of projects well. It's all about tradeoffs.


    "Anything in the middle just gets ugly, no matter what your ancient dinosaur o-r mapping advocates will tell you... "

    Again, I disagree, and it's this attitude that has helped cause the failure of the OODBMS market from the early 90's... this elitism that we somehow are forced to throw out all our investments in DBAs and RDBMS theory because objects just don't "work" in an RDBMS. This is patently absurd. It's all about tradeoffs, and the ODBMS approach has a certain set of inherent tradeoffs: you're moving back towards a pointer-based model of data storage, any data access paths must be known a priori. Ad hoc data access requires a fair amount of custom infrastructure to support in an OODBMS -- some vendors provide support for SQL-like querying, but this is usually rather limited.

    How can one solve problems with a "pure relational approach" unless you wrote 90% of the system with stored procedures? That's moving behind modern software architecture.

    Most Java enterprise systems today write their own custom / crude O/R mapping, usually delegating to stored procedures, and it more or less works. Its cleanliness depends directly on the ability of the team to find the right balance between OO abstraction and the necessary binding to the undelrying SQL structures. Naturally a tool like TOPLink helps in this case, but it depends on the complexity of your model.

    To suggest that O/R mapping is a mess "no matter what" is wrong, in my opinion. There's a continuum of tradeoffs. f you have a simple application and data model, then you don't need O/R mapping. If you have a moderate complexity model, O/R mapping is useful. If you have a complex data and/or behavior model, an ODBMS becomes the better option.
  16. As reposne to Stu:
    The difficulties revolving traditional O/R mapping - home made balance between Stored procedure and application relevant object module emphasizes the need for current cmp engines to evovle.
    The must offer a valid-performance alternative, meaning - they have to speed up and support more access strategies and with greater tendecey to store as much as data in memory as possible (and ditriburte to other cluster nodes).

    yuval.
  17. Interesting discussion here.

    > Production Gemstone instances need a fair amount of TLC...

    I certainly agree with Stu that a production GemStone DB needs an experienced admin. There is a lot of performance tweaking available with this product with multiple extents, cluster buckets (grouping objects together for fast access), and especially two things - garbage collection and instance transforms.

    "GemStone Admins" need to be a combination sysadmin and Java developer as well. Many of the management APIs are all Java based. Performance is highly tied to how an app uses the shared cache. GemStone offers a lot of architectural flexibility - and very high performance when implemented correctly.

    (Mind you, my perspective is from a few years of GemStone/J experience and not from the evolved Facets product.)

    Even complex data models that need an OODBMS for modelling often have some requirements that are best suited for a plain relational database. Hundreds of thousands of simple "history" or "event" records that will never change once created are a good candidate for relational storage - much better than having to run instance transforms on them in GemStone.

    If the admin tools (and architectural frameworks) available for GemStone Facets evolve to the maturity of GemStone/S (the Smalltalk equivalent) - and some "success stories" emerge, it could gain a lot of momentum (and market share.) Having an established base of loyal GemStone developers will certainly help with this as well.

    GemStone Facets + JBoss should be seriously considered as an alternative to many BEA + Oracle (or equivalent) EJB solutions. GemStone's distributed object cache is a great product!
  18. Can't we all just get along? :) There's not a lot to be gained by arguing the merits of RDBMS vs. ODBMS anymore. In my experience selling GemStone for years, the choice is rarely a technical one anyway.
    <p>
    Sure, there are people that have enjoyed and will continue to use GemStone (S, J, Facets) as an Object Database, but if it truely is a great product, its application will bridge gaps in technology and not carve canyons.
    For me, the ultimate goal is being able to separate the application layer from the storage layer. Application programmers should not see the particulars of the storage architecture creeping into their code or their performance stats. I cringe when I see data retrieval methods that are specialized according to the indended use of the data (get deep objects vs. wide objects).
    <p>
    I meet so many talented programmers in my travels that I just don't understand why my phone company will call me up to try to sell me a service that I cancelled the day before. Why aren't our corporate computer systems a lot better than they are? Where is my flying car? We, as software vendors, still haven't come up with the right combination of features that will set your imaginations free.
    <p>
    So back to my goal. Since I am actually the guy who gets to sit in the room and say "I think our customers would buy 'x'", you can send your disappointments to me. Our JBoss Caching Demo was meant to help bridge a gap. We attempted to prototype, with more to come, using Facets as a buffer between the Applications and the RDBMS - put a cache in the middle that not only improves peformance, but compensates for the impedence mismatch between objects and tables. Application programers see nothing but pure, unrestricted object domains with the added support of ACID transactions, locking and security. They are isolated from change to the back end in the same way you can twist the cookie parts of an Oreo in opposite directions without affecting its taste (yeah, but try to resist pulling them apart to lick the frosting). Your O-R Mapper of choice runs almost synchronously, efficiently processing updates in batch without making the application wait for completion. And life is, once again, good - or at least a tiny bit better.
    <p>
    Okay, so it's not just my goal. The good folks who are working on CMP might have the same good idea (of course they do). However, as much as I think the 2.0 version of the CMP spec is a great advancement over its predecesor, I'm still troubled by Dependent Variable Classes being serialized and stuffed into blobs. That solution is not optimized for queries (can't really do 'em) or retrieval (you have to bring it the whole thing back at once and you must re-establish identity relationships). So, instead of just complaining, I'm going to try to do something about it. Please stay tuned. I look forward to the day when an EntityBean, rich in application logic but devoid of business logic, becomes a portal into a powerful, diverse and beautifully crafted, pure object network - one that can be shared by Beans, Servlets, GUIs and daemon processes alike.
    <p>
    Thank you for reading this far. Please accept my appologies if my view of what needs to be done and what has been achieved so far differs wildly from yours. For those of you who have cast their pennies into this, TheServerSide wishing well - make sure you join our friends from JBoss at the ThirstyBear at JavaOne. Christmas might just come in March this year.

    David Brown
    Technical Director
    GemStone Systems Inc.
    david dot brown at gemstone dot com