Stored procedures have performance benefits and also provide a uniform implementation when you have Java and other languages using the same resources. If some client insists on using stored procedures use JDBC. You can call stored procedures from POJOs or old-style EJB code. Cash client check as usual.
If a client insists on stored procedures exclusivesly, recommend a native language to develop their app. PL/SQL for example. If they want to use EJB 3.0 for persistence, cash the check, and use session beans. You could also explain that it's an idiotic requirement and walk. Seems to me the "out" parameters of stored procedures will make it difficult to generalize, and it's even more egregious than native SQL in terms of portability. You can call stored procedures using JDBC when the exceptional case arises, but I will lose no sleep if they never consider them for entity manager. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3927629#3927629 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3927629 ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ JBoss-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-user
