After getting the ticket list, I will have to read the employeeIds first in memory then make those calls and put 'em in a hashmap so that I can disply 'em properly in the hashmap.
On 4/7/06, olonga henry <[EMAIL PROTECTED]> wrote: > > 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<http://employee.name/>like "John Smith" > > AND Employee.id <http://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] > > > > >
