On 4/7/06, olonga henry <[EMAIL PROTECTED]> wrote:
> That's what I am talking about this is a situation which needs JTA
> transaction manager otherwise how would spring handle distributed
> transactions.
I think (assume) spring has a built-in support for this (declarative
transaction an all).
I don't even know what do you mean by " good application (at
> least a good co-oriented application)
> shouldn't use joins or distributed transactions", I mean have you never done
> a SQL-JOIN before???
In a "good" application you don't need joins, because your data model
is well separated in the business layers, and you "join" data at
business layer.
Example,
you need all tickets managed by an employee with name John Smith:
in sql you would do something like
select * from Ticket, Employee, where Employee.name like "John Smith"
AND Employee.id = Ticket.employeeId;
This is SLOW.
In co-architecture you do:
EmployeeId eId = EmployeeManager.getEmployeeByName("John Smith");
List<Ticket> tickets = TicketManager.getTicketsByEmployee(eId);
No SQL-JOIN -> FAST ;-)
regards
Leon
>
> On 4/7/06, Leon Rosenberg <[EMAIL PROTECTED]> wrote:
> >
> > I think spring will handle the transactions for you, if you want to do
> > it yourself, you'll do it in the dao objects, or in case of a
> > 2-phase-commit, start and commit the transaction in the "business
> > manager" and extend your dao object to support 2-phase commits
> > accordingly.
> >
> > However, a good application (at least a good co-oriented application)
> > shouldn't use joins or distributed transactions.
> >
> > regards
> > leon
> >
> > On 4/7/06, olonga henry <[EMAIL PROTECTED]> wrote:
> > > But what about Transaction demarcation, where does JTA come into play?
> > >
> > > On 4/6/06, Leon Rosenberg <[EMAIL PROTECTED]> wrote:
> > > >
> > > > to complete to Joes very good suggestion: the business manager returns
> > > > service an object/list of objects which are in no way associated with
> > > > objects used in dao. The typical name for this kind of object would be
> > > > a TicketDTO. The struts action maps each TicketDTO into a TicketBean,
> > > > which is the only object known in the jsp. This way you'll get stable
> > > > layers and don't rely on the db design in the jsp and vice versa.
> > > >
> > > > regards
> > > > Leon
> > > >
> > > > On 4/6/06, Joe Germuska <[EMAIL PROTECTED]> wrote:
> > > > > JSTL SQL calls don't conform to MVC principles in any way at all.
> > > > >
> > > > > I'd suggest creating a business manager service in Spring which has
> > > > > access to the two DAOs and having a Struts action call a single
> > > > > method on that business manager. This one sounds like read only,
> > > > > but if you have write operations, this allows you to use Spring's
> > > > > declarative transaction handling to integrate both databases into a
> > > > > single transaction.
> > > > >
> > > > > hope this helps...
> > > > >
> > > > > Joe
> > > > >
> > > > >
> > > > > At 4:09 PM -0500 4/6/06, olonga henry wrote:
> > > > > >Using Struts-Spring-Hibernate:
> > > > > >
> > > > > >I have a situation where I have to fetch a list of records from a
> > table
> > > > > >'Ticket' (in database 1) in which a column is a employeeId so my
> > action
> > > > > >class calls the service layer which in turns calls the DAO layer to
> > get
> > > > the
> > > > > >"Certain Tickets List".
> > > > > >
> > > > > >Now, there is another table 'Employee' (in database 2) which
> > contains
> > > > > >employeeId and employeeName columns. In order to display the list
> > of
> > > > > >tickets with the employee names (in place of the employee Ids), I
> > could
> > > > have
> > > > > >done a join if both the tables were in one database, which I cannot
> > do
> > > > in
> > > > > >this case.
> > > > > >
> > > > > >I can make JSTL SQL calls to database 2 - Employee table to find
> > the
> > > > names
> > > > > >at the view layer. But I would like to know if there are better
> > > > > >alternatives out there which confirm to MVC principles.
> > > > > >
> > > > > >Thanx
> > > > >
> > > > >
> > > > > --
> > > > > Joe Germuska
> > > > > [EMAIL PROTECTED] * http://blog.germuska.com
> > > > >
> > > > > "You really can't burn anything out by trying something new, and
> > > > > even if you can burn it out, it can be fixed. Try something new."
> > > > > -- Robert Moog
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
