Thanks leon, what you are saying applies well to your sitation, but my situation is different.
I have to do this first: List<Ticket> tickets = TicketManager.getTickets( ticketStatus ); now each ticket record has an employeeId associated with it. Then I will have to go back to 'Employee' for each of them: String EmployeeName = EmployeeManager.getEmployeeNameById( 3333 ); So if there are 30 tickets open then there are 30 call to the database by this approach. But wich JOIN it's one call if both of them were in one database. But you will still have to use JtaTransactionManager in my case because Spring needs this TransactionManager so that it can handle multiple data resources: read this: http://openframework.or.kr/JSPWiki/Wiki.jsp?page=Data+Access+using+O/R+Mappers On 4/7/06, Leon Rosenberg <[EMAIL PROTECTED]> wrote: > > 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] > >
