4 Replies Latest reply on May 15, 2004 7:05 PM by acoliver

    Last minute major revisions to M1 (uh oh)

    acoliver

      I set about trying to make some minor config changes to the Entity store behind the EntityMailbox implementation. I tried to just switch to option A and use read-ahead for the rest. I then discovered....it is all running with no transactions what-so-ever... There is no session fascade or anything. So I'm making some fairly major changes to M1 which I'll also commit to the M2 branch. While these are pretty big changes I'll be using it as my mail server and if it breaks things you can bet we'll know ;-) If nothing real bad happens I'll do M1-final on Monday (finally) and we can wait for the fallout ;-)

        • 1. Re: Last minute major revisions to M1 (uh oh)

          Sounds good :)

          • 2. Re: Last minute major revisions to M1 (uh oh)
            acoliver

            Hehe we'll see how you feel about it on monday ;-)

            Basic outline of the changes:

            EntityFolder now delegates everything to a Session Bean
            EntityMessage is now option A with read-ahead on find/page size 500 for all fields (a *little* dangerous, but I think its fine for now)

            The value objects are now loaded "on load" instead of in the session bean (caching/read-ahead performance depends on this).

            We really need to rework this whole mailbox structure. Mike had some ideas on that (but I think he was going to far to the uber-normalized/complicated side). Ultimately I want hibernate to be default but I think we need more hibernate-jboss plumbing first (hibernate-session management for one, deployer for antoher)

            • 3. Re: Last minute major revisions to M1 (uh oh)
              mikea-xoba

              sounds like a good idea andy.

              i'm not so hot either on my original idea anymore, mostly because i'm not sure how it would affect performance. actually, i think its worth avoiding any significant performance issues in OLTP systems, including mail handling.

              i should really dig into hibernate sometime soon and see what its benefits are. so far i've limited myself to entity beans, and before that, custom-written sql middleware hell. but if you could say in a nutshell what the advantages may be over entity beans in our application, that'd be super.

              mike

              • 4. Re: Last minute major revisions to M1 (uh oh)
                acoliver

                Don't misunderstand me. We shan't be droping support for an Entity backend. The whole thing needs to be pluggable. Hibernate should just be default.

                The benefits of hibernate: No ejb interface hell :-) -- a cleaner concept of caching, more fine grained control and its just faster. Its the closest thing to pojo persistence to date.

                What sucks about hibernate: I don't like having to programatically deal with the session object, transactions and the like. No deployer for JBoss yet (you have to sar it all up with hibernate. The way it ties in kind of violates the ejb spec more or less.

                What we need is a HibernateDeployer which reads a hibernate.xml. We need a session manager mbean which lets you hide session management from you . We need an interceptor which works with the session manager mbean. Etc etc... This is the general things that JBoss needs with regards to hibernate as well... (gosh I bet I get an australian bar-b-queing for this post ;-) -- you gave me a draft of the book...its your fault)