Nicholas wrote: > > --- Joe Schell <[EMAIL PROTECTED]> wrote: > > Dimitar Stavrakov wrote: > > > > > > > This can be done without a EJB container. There are > > a number of free > > and commercial implementations that do it. > > The free and commercial implementations are all very > nice, but do search on the web for someone who knows > "Ernest Does Database Persistence 2.0 (EDDP2)" and > then compare that to the same for EJB. (Adjust for > people who actually really know what they say they > know.) >
I don't understand your reference and neither does google. I did try some alternatives and most if not all of the documentation was specific to containers so I wasn't quite sure how to qualify if the actually knew what they were talking about. > > > > > transaction management, etc. > > > > You have to be more specific. JDBC does > > transactions. > > > > yes, but it does not do transaction management. That still doesn't explain it. Doing searches on the web seems to suggest that there most references seem to think that there is little or no difference. So perhaps you could provide an example or a reference that explains the difference? > > > > When you're using EJBs all these are ready for > > > you to use, without having to write a single line > > of code. You can't beat > > > that with straight JDBC coding. > > > > Using all of that functionality, especially the > > first time for each > > different container, takes a non-trivial amount of > > time to configure and > > tune. There is probably an EJB container that > > provides easy and clear > > documentation that makes such chores a breeze. > > However I haven't seen > > it nor heard of it. (I spent a week one time trying > > to get a container > > set up to do connection pooling with a particular > > database and driver > > and I finally had to give up.) That time also > > counts against the total > > time for coding any new implementations. > > > > > > Ok, so instead of spending a non-trivial time > configuring a server that at least adheres to some or > all of a fairly straight forward spec, we will all > invest time learning some third party, non-standard, > BETTER DOCUMENTED java database framework ? > > I hear you that some of these products are hard to > use, but that is because they are addressing a hard > problem and/or they just suck. > I do not understand your point. I was trying to point out that understanding how to configure the container so it uses those wonderful features takes time. And is sometimes impossible. The alternative is writing code to do some or all of the same thing. Presumably if someone writes the code then they do understand how to use it. Naturally one alternative is to hire and expert from the container vendor and have them configure it correctly. But whether one figures it out themself or hires an expert it still costs. And that step must be factored into the calculation of the overall cost of the two alternatives. =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
