Hi everybody, I've been reading a bit further into JTA spec's and have understood that, in a web application, the application server is responsible for providing as many INDEPENDENT transactions as requested by each user's Session (thread). On the top of that, since I won't be using distributed objects, but everything will be finally local (one server, one JVM, that is), there won't be any distributed transactions. Therefore, neither will I need the "XA" objects, but only the "traditional" JDBC objects (Connection, Statement / PreparedStatement, etc...).
As I got it, JTA will have control over all JDBC statements executed anyways, hence be able to control their transactional execution. This is what I've concluded so far. If I'm wrong (at all or in some part), please don't hesitate on telling me. Anyway, thanks everybody for your time and patience. Pardon my ignorance on this topic. Regards, Freddy. -----Mensaje original----- De: Mark Lowe [mailto:[EMAIL PROTECTED] Enviado el: lunes, 29 de marzo de 2004 12:38 Para: Struts Users Mailing List Asunto: Re: [OT] JTA, JDBC and data persistence +1 Hibernate, xdoclet . mail me off the list if you want an example build.xml file. Hibernate uses POJO approach, and xdoclet tags makes light work of the xml mapping files as well as making you hibernate java beans mean something more than a bunch of gets and sets. I'd buy xdoclet in action and look at chapter 7 rather than give any coin to some suits by paying for "training courses" that wont really help anyway. I'm stupid (unbelievably so) and i manage it. HTH mark On 29 Mar 2004, at 12:19, Joe Hertz wrote: > Freddy - > > Pardon me here, but I really am curious, what exactly are the > backgrounds of > your developers? Youre saying they can all handle JDBC calls complete > with > rolling their own SQL, but don't understand the concept that an O/R > Mapping > tool is based on?? > > I'm not getting it. What exactly about their expertise is stopping you > here? > > If the situation is like this: "Many of them don't know anything about > databases, but of the ones who do, they all understand JDBC and only > one or > two know O/R Mapping tools", then I'd go for the O/R Mapping tool > anyway, > here's why: > > The hard part about the typical O/R mapping tool is the setup and > configuration. Theyre goal in life is to allow you to deal with POJOs > which > should make it *easier* on your developers. As opposed to needing to > extract > fields out of your Objects and putting them into SQL syntax. Ultimately > everyone is going to use some common set of methods thats talk to your > database anyway, right? > > In your situation, if you can handle the set up end of it, I'd be > doing that > up asap and providing the "application level" developers examples of > how to > do the (relatively simple by comparison) stuff they need to handle. > > For example with Hibernate, unless your object model is changing ALL > THE > TIME, the developers would just need to learn the Session API, and > that's > hideously simple. I suspect your non database literate developers will > be > able to understand it faster than they will JDBC. (If HQL is the > holdup, > iBatis solves that problem). > > I mean, how tough is something like this to understand? > > Session session = this.obtainSession(request); > session.load(myObject,myKeyValue); > myObject.setProperty(myValue); > session.save(myObject); > session.flush(); > session.connection().commit(); > this.releaseSession(); > > -Joe > >> -----Original Message----- >> From: Freddy Villalba Arias [mailto:[EMAIL PROTECTED] >> Sent: Monday, March 29, 2004 2:34 AM >> To: Struts Users Mailing List >> Subject: RE: [OT] JTA, JDBC and data persistence >> >> >> Hi everybody, >> >> Yes, I'm aware that this is the typical scenario for a O/R >> mapping tool (Hibernate, OJB... you mention it). I've done so >> in several other projects. The problem in this case is time: >> there is not enough to have training sessions on any of those >> tools for the members of the development team; they do not >> have experience with any of those mapping tools, many of them >> not even know the concepts they are base on. Therefore, I'm >> somewhat forced to go for the POJO option, despite my knowing >> it's not the best / more adecuate one. >> >> Regarding JTA vs JDBC, I understand that using JDBC >> inevitably forces you to "hardcode" transction management, >> and being it distributed (in some cases) along different >> objects, it's specially cumbersome and, IMO, a bad design >> choice. I believe (from what I've read) that JTA precisely >> address that issue. >> >> Again, if I'm wrong, let me know so. In any case, any help >> regarding this JTA-related topics would be appreciated. >> >> Thanx and regards. >> >> -----Mensaje original----- >> De: Bill Siggelkow [mailto:[EMAIL PROTECTED] >> Enviado el: viernes, 26 de marzo de 2004 19:13 >> Para: [EMAIL PROTECTED] >> Asunto: Re: [OT] JTA, JDBC and data persistence >> >> Freddy, I think you only need to look into using JTA and XA >> transactions >> >> if you are spanning multiple data sources (databases). If >> you are not, >> then I would look into using an Object-relational mapping tool like >> Hibernate or OJB to do what you want to do. These tools >> usually provide >> >> support for transactions, in addition to providing a >> mapping layer for >> >> your objects. >> >> Freddy Villalba Arias wrote: >>> Hello everybody, >>> >>> >>> >>> An off-topic question (it's Friday, I hope you accept it!): >>> >>> >>> >>> I want to implement a Business Object Model on top of many >> DAOs. Those >>> BOs will be - obviously - related to each other (mainly 1:n and m:n >>> relationships). >>> >>> >>> >>> I must implement this in such way that, when - for example >> - deleting >> a >>> BO that has 3 children associated (therefore, those must be >> deleted as >>> well), it's is possible to do so atomically. That is, I need to be >> able >>> to delimit the beginning and the end of the transaction >> that spans the >>> delete operation on those 4 objects. >>> >> >>> >>> >>> I want this to be as transparent and "elegant" as possible. >> I believe >>> the right choice for solving this is using JTA objects (that is "XA" >>> objects) instead of plain JDBC. I've been reading the API and some >>> papers regarding JTA; I have a fundamental doubt: >>> >>> >>> >>> Does JTA allows me to delimit (and perform) 2 independent, yet >>> concurrent transactions??? For instance: 2 users that click the >> "delete" >>> button at the same time (it's a web application). >>> >>> >>> >>> I haven't seen anything like a transaction ID or similar on any >> example >>> I've examined. Is this issue transparent to me? Is JTA able, in any >> way, >>> to differentiate the Transaction begun from each user's >> corresponding >>> instance of the respective BO (the one they wanted to delete... i.e. >> the >>> father, not its children)??? >>> >>> >>> >>> I'd appreciate any light you can shed on this matter. >>> >>> >>> >>> Thanks and regards, >>> >>> Freddy. >>> >>> >> >> >> --------------------------------------------------------------------- >> 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
