k ... this work is now in the trunk, so anyone who is interested can
check it out there or review the changes in revision 475368
-- Allen
Allen Gilliland wrote:
Anil Gangolli wrote:
This actually has to do with the use of Hibernate Contextual Sessions
( the thread-bound session returned by getCurrentSession() ), not
Hibernate's behavior when using JDBC transaction semantics.
http://www.hibernate.org/hib_docs/v3/reference/en/html/architecture.html#architecture-current-session
We might want to consider using the ManagedSessionContext for this and
managing the session binding/opening/closing ourselves; that might be
cleaner and more localized than trying to manage flush() ourselves.
The problem with managing flush() explicitly is that it tends to lead
to having to assume boundaries in composition of operations (where the
flush() is called). For example, if you query as part of a method you
have to flush or know that flush is not necessary.
I am definitely interested in exploring this more. I have completed
what I originally set out to do and so far from my testing everything
seems to be working properly and the load testing that I have done has
shown some improvements here and there, but not all that I was hoping
for. Part of the reason there wasn't as big of a performance
improvement definitely may be due to the use of FlushMode.NEVER, so I
plan to investigate that as best I can and see if there are better
alternatives.
If you have any other ideas then definitely send them out and I will
attempt to try them out and see what kind of impact they have.
Also, looking back at the initial message, I was confused by the
phrase "2) enabling lazy fetching on all objects and
associations" in Allen's message. Did you mean all single and
collection-valued associations? I don't think lazy fetching of object
properties will be a win at all.
Good point. Yes, I meant only for single and collection-valued
associations, which is what I believe Hibernate defaults to right now.
Now that I have everything working I plan to go back and do a bit more
rigorous debugging to double check this and make sure, but I am pretty
sure this is the case.
In any case, I would agree that lazy fetching for all properties would
be silly.
We might also consider using join fetching for certain associations,
particularly around weblog entry data. Maybe you looked at this already?
Nope, I haven't gotten that far. I am certainly open to this though, so
if you have time to offer up a few more details I can try experimenting
with it.
-- Allen
--a.
----- Original Message ----- From: "Allen Gilliland"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, November 14, 2006 11:16 AM
Subject: Re: Business layer cleanup for 3.2
Craig L Russell wrote:
On Nov 14, 2006, at 9:48 AM, Allen Gilliland wrote:
It's not unlikely that we will break some things temporarily and
not notice it for a while. The riskiest aspect to me in this
regard is lazy fetching because it really demands that the session
span the entire request, which we seemed to have a hard time doing
properly earlier, and I'm not sure exactly why. We backed out of
lazy fetching just before one release a ways back because we would
hit odd session closed exceptions that we didn't have time to
figure out. It's possible that some of Allen's earlier session
management cleanups already got us out of those issues. It's a
good idea to revisit this now. I think that is also likely to
make us more portable to optimizations in other persistence
implementations that expect essentially the same session
management pattern.
so far I have been able to make all the changes that I think are
correct and I have all the unit tests running correctly, so what I
am doing now is going over the actual webapp and running through
all the operations that I can to find and fix anything that I
find. Things are definitely cropping up, but so far the lazy
initialization problem hasn't come up.
The bigger problem has been caused by changing the hibernate config
to use FlushMode.NEVER, which means that hibernate doesn't flush
its state to the db until we explicitly call the flush() method on
the Session. As it turns out, a *lot* of the stuff we were doing
has been very reliant on auto flushing for it to work, so there
have been a handful of places where I have had to figure out how to
fix that problem. So far so good though, and I hope to have things
cleaned up enough to commit in the next day or so.
What is the reason you want to set hibernate config to use
FlushMode.NEVER? From what I know of it, this is an antipattern.
I will do some more reading about it because if it is an antipattern
then I should reconsider it, but the main reason why I am trying this
now is to get around some of Hibernates automation. The main problem
being that Hibernate's default handling for JDBCTransactions is setup
such that whenever you commit a transaction it closes the Session
that was handling that transaction, and that causes a problem with
lazy initialization because objects can no longer access associations
if the Session they were attached to is closed. I sifted through
things on the Hibernate forums to find other folks with the same
problem and how they fixed it and that's where I came up with
FlushMode.NEVER.
It may be possible that we can accomplish that without using
FlushMode.NEVER, but i'll have to look at it more carefully to see.
Regardless of whether or not we use it I still think that in
principal it should work. The places where I have found things
broken by this change is situations where we are kind of
circumventing our object model and going directly to the db which
causes a slight disconnect. i.e. if I call saveObject(foo) and then
later in the same transaction try to getObject(foo) via a query
before it has been flushed to the db. So far these scenarios look
more like slightly incorrect code as much as anything else, but I am
still investigating.
I'll look into this more today though.
-- Allen
Craig
-- Allen
--a.
----- Original Message ----- From: "Allen Gilliland"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, November 13, 2006 4:46 PM
Subject: Re: Business layer cleanup for 3.2
certainly. I didn't do much in the way of renaming things yet,
the first pass was mainly about fixing up the Hibernate config to
work the way I think it should have been working and clearing out
some things along the way. Once that is done then I plan to go
over the business layer more times and find places where methods
should be renamed, removed, or consolidated in any way. I also
want to keep building on the unit tests because I think they are
pretty good now, but there are a few gaps here and there.
At the end of the day this work will definitely help to make the
work on the JDO/JPA backends quite a bit easier.
-- Allen
Craig L Russell wrote:
Hi Allen,
We had discussed a number of issues with the manager classes
such as misspelled method names and incomplete functionality
(having the caller iterate through collections).
I'd be happy to review what you've done in terms of cleanup.
Regards,
Craig
On Nov 13, 2006, at 2:10 PM, Allen Gilliland wrote:
One of the things that I am planning to do for the 3.2 release
is do some audit/cleanup of the current business layer code.
There are a variety of things which could use improving, but
the main goal is to fix our Hibernate configuration so that we
are 1) properly using the open session in view pattern and 2)
enabling lazy fetching on all objects and associations.
Right now our Hibernate config is pretty messy and doesn't take
advantage of many of Hibernate's performance features, so the
main reason to do this work is to improve the performance of
the business layer. The second big reason is just to reduce
clutter and simplify the code as much as possible. There are
plenty of places in the code where we have methods that aren't
used at all or methods which are duplicated, so those would all
be cleaned up.
I have most of this work done already (but not checked in) and
there aren't really any surprise changes that I had to make
except when it came to the hierarchical objects. I tried for
multiple days to get the hierarchical objects to work with the
updated hibernate config and the current data model, but I kept
running into problems. So to fix the problem I had to make a
small tweak to the way hierarchical objects are persisted which
fixed my issues and I believe drastically simplifies the
problem overall. The basic change is that I have completely
removed the HierarchicalPersistentObject class and Assoc and
it's subclasses and changed the data model so that we have a
more normal hierarchical model.
So, for weblog categories I added a simple 'parentid' column to
the weblogcategory table and that allows a category to manage
relationships between it's parent and children directly. Same
goes for the FolderData class, but as it turns out that column
already existed in the schema but wasn't being used. Upgrade
path for both of these is fairly simple and only requires
populating these columns with the right value.
I'm not sure if anyone really wants to see more of a proposal
for this, which is why I started with an adhoc description here
on the list. As I said, I am not actually modifying anything
from a feature point of view, only cleaning up what is already
there. If anyone wants to see more about the changes to the
hierarchical objects then I can post them on the wiki or
something.
-- Allen
Craig Russell
Architect, Sun Java Enterprise System
http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
