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!
