Hi, This is the situation (more or less):
Most of them don't have notions / experience on certain basic concepts (like - for instance - design patterns). They are used to coding their SQL throughout the code, utilizing (in a few cases) a single DB access object that is nothing but an SQL executor (and logger). None of them are used to those concepts related to O/R mapping and persistence (persistence ID, Persistence Manager, persistent object, etc...). The times were underestimated to an unbelievable point. I was not asked for advice on that matter, especially since I was not even on this project at that time. In addition to this, the most important problems here are political (the project was granted to these 2-companies joint proposal). Believe me, it's more complicated than it sounds and I don't have control over certain key decisions. On the top of that, I've just been assigned this team (with no possibility to include / exclude anyone) and a task: get it done, on time. I perfectly understand all of your arguments, count myself as a supporter of O/R mapping tools (I even had my own developed for the project I was working before this one), but - as you can see - it's more than just assuming the learning curve or taking the chance. I don't have experience with JTA, but from what I've read so far, it seems like anybody (with a basic understanding of database access through JDBC) could easily learn and apply (the basic aspects, that is). Hence my question. Thanks everybody for your feedback! Will appreciate anything else you can provide on this matter. F. -----Mensaje original----- De: Joe Hertz [mailto:[EMAIL PROTECTED] Enviado el: lunes, 29 de marzo de 2004 12:20 Para: [EMAIL PROTECTED] Asunto: RE: [OT] JTA, JDBC and data persistence 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]
