> ... But normally jsp client are without Transaction context A web container hosted in a J2EE app server will always provide a user transaction to JSPs/Servlets.
.>... If they have already commit or rollback functionality in SPs then why to remove that. Will it pose problem for me in above scenario You loose the possibility to call several sp's from your java code (within the same web request), since they will commit independently of each other. Using commit in your sp's leaves you with one single option: Your complete business logic (the processing started by a http request) may make only ONE call to a sp. This may be fine to your particular situation, but it is rarely of general interest ;-) If you commit in your sp, you should make that clear by declaring your EJBs as NotSupport, to avoid conflicts with J2EE transactions. /Johan -----Original Message----- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Ashwani Kalra Sent: den 17 juli 2002 14:04 To: [EMAIL PROTECTED] Subject: Re: Why Ejb? Hi, Yes I know you can get javax UserTransaction interface. But normally jsp client are without Transaction context. So my whole point was publish the functionality in the form of business fn in session beans remote interface with appropriate transaction attributes(So the container automatically initialize the transaction context for such clients) and call SP from those fns.If they have already commit or rollback functionality in SPs then why to remove that. Will it pose problem for me in above scenario? /Ashwani ----- Original Message ----- From: "Johan Eltes" <[EMAIL PROTECTED]> To: "Ashwani Kalra" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, July 17, 2002 4:57 PM Subject: RE: Why Ejb? > > > From where that transaction context comes if I dont use session beans etc > > with transaction attributes set. > >... > >If I am not using EJbs , why that would be silly. Where I will commit my > >transaction. > > In J2EE you use the User Transaction interface to begin/commit/rollback > transactions - either indirectly using EJB and container-managed > transactions or directly. But you never use the commit/rollback methods of > the jdbc Connection interface. This model is fundamental for creating > autonomous components that can be composed into systems. Each component (EJB > or any Java class called within an app-server controlled transaction) can > create, use and close jdbc connections as if they were the complete business > logic. When several components are called in the same app server > transaction, each of them will get a datasource, create a connection, use it > and close it - but never call commit/rollback on it. The app server or EJB > container will assure that the same (open) jdbc connection is handed over to > each of the components when they ask a datasource to "create" a jdbc > connection. > There is a lot more to say on this topic, but it will hopefully give you an > idea of the responsibility of the application server vs. the programmer > (component provider). > You do not have to use EJBs to get the programming model outlined above. If > your application is a web component, you can look-up and use the User > Transaction directly from your servlet (to begin and commit the > transaction). You can then use regular Java Beans / classes to access/update > the database using datasources and jdbc connections exactly the same way as > you would if you coded jdbc calls in your session- or BMP EJBs. > /Johan > > =========================================================================== 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". =========================================================================== 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".
