I'm definitely -1 on part item 2 of your proposal.
I do not understand what you are proposing to do and I'd like to see
specifically how each action and method in the back-end will change.
There are many multi-step queries, updates, inserts, etc. in the code
and application logic is expressed in both Struts actions and in the
back-end. I don't think you are adequately explaining how you will
keep transaction demarcation in place. And I don't understand how you
can move begin() and commit() the back-end without moving lots of
code from the Struts actions into the manager classes.
To do this right you'll have to do some trail and error
experimentation and in the end I believe you'll have to make
extensive changes. I'd like to have community review of those changes
before they goes in trunk. For that reason, I strongly suggest doing
item 2 in a separate branch.
- Dave
On Mar 8, 2006, at 6:40 PM, Allen Gilliland wrote:
just a reminder, silence == consent. i am planning to move forward
with development on this.
-- Allen
On Mon, 2006-03-06 at 13:25, Allen Gilliland wrote:
Okay, here is a more flushed out proposal of what I think should
be done ...
http://rollerweblogger.org/wiki/Wiki.jsp?
page=Proposal_BackendRefactorings
Note that the driving force behind these changes is to 1) prevent
direct access to the PersistenceStrategy from outside the business
layer and 2) limit persistence logic (like transaction details) to
the business layer.
I think those are very appropriate goals to have for the
architecture of our code.
-- Allen
On Sun, 2006-03-05 at 10:10, Anil Gangolli wrote:
Anil Gangolli wrote:
Actually, you want those two queries to be in one transaction, not
two; otherwise they can see inconsistent state if there is another
transaction committed between the two.
Red herring on my part. Not really a new issue for us though
since we
are typically using default READ_COMMITTED isolation anyway.
--a.
