On 4/7/06, olonga henry <[EMAIL PROTECTED]> wrote: > That's Right, there are multiple issues here that involves > JTATransactionManager which I can deal with. However what I am asking here > is more of a design pattern type (between dao layer and business > logic/service layer) of question on how do you handle such a scenario where > after gettting list of tickets which has many-to-one relationship with > another table 'Employee' (in a separate legacy database), and you have to > display the names instead of the ids. > > Tables are laid like this: > Ticket (ticket_id, description, emp_id) > Employee(emp_id, emp_name)
When I need to merge data from two different queries, or merge data from two different databases, I usually bring back both datasets, and then do whatever I need to do in plain old Java. The basic pattern would still be business facade. You put all the nasty Java code that reconciles the data coming from two different sources between a single method. The method makes as many database calls as needed, churns the data, and returns the result -- as if it were the simplest thing in the world to do :) If the facade also has to update both databases, and Hibernate isn't up to the task of keeping transactions open on both databases until both complete, I'd probably drop back to plain old JDBC and do it the old fashioned way. Alternatively, I'd try the old MySQL approach and lock both tables to obviate the possibility of failure and rollback. At this level, its really more of a Hibernate/data access question than anything else. Whatever you do, the best practice would be todo it all behind a facade that keeps the web layer out of the picture. HTH, Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
