Re: [OT] JTA, JDBC and data persistence

[Mark Lowe]

+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]