<resending this because my machine crashed when sending this earlier... apologies if I'm repeating myself>
We did this same scenario at IBS a few years back with PeopleSoft's Campus and HR products. I do not know about other 4GL products, but PeopleSoft is not transactional so, as Tracy points out, the last update wins. Our approach in using EJBs with Peoplesoft was to let the EJBs wrap the calls to PeopleSoft -- very little business logic was done in the EJBs. This prevented having conflicting business logic and obviated most security issues. For performance reasons, we would do database reads on most PeopleSoft tables and do updates on tables that were "safe" to update without using a Message Definition -- that is, tables that did not have 4GL triggers. We had developed Object-to-Resource tools to generate Java CMP for PeopleSoft Message definitions. That worked fine. Early on I built a PeopleSoft ResourceManager to run with our transaction service, but later discarded it because of the non-transactionality of PeopleSoft. However, I believe that a ResourceManager similar to what is used in JMS might be possible where the updates to PeopleSoft are held until the commit phase. The failure in this approach is that table accesses following the call to the Message definitions would not correctly reflect the state of the table that ought to exist if the Message def were executed when expected. You can still do this approach if you keep this serious drawback in mind in writing your EJBs (basically, perform the Message Defs last). If the 4GL application can be made to honour distributed transactions then a viable ResourceManager for it can be created. I never approached this problem before, and not being cognizant of PeopleSoft or other 4GL application internals, I cannot say how easy it would be to intercept calls for database connections. If PeopleSoft (or other 4GL application) connection pooling can be replaced with a customized connection pool, then it may be possible to make PeopleSoft "distributed transactional", which would then allow you to intermix Message Definition calls with other database calls in the same transaction context. Cheers, Frank Gates [EMAIL PROTECTED] "Nelson, Tracy" wrote: > From: Rohit Parik [mailto:[EMAIL PROTECTED]] > Subject: Common datasource to two applications > > | Suppose there are two application, one a 4GL based application > | and one based on J2EE which uses CMP entity beans. > | > | Now if the components of both these application use the same > | database tables on the same data source what sort of > | issues / problems can arise? > > You'll have problems related to concurrent updates (the "last one > wins" scenario). If you implement any sort of security in your > application, the other may not respect it. If you have any > business logic that is implemented differently between the two, > they may report invalid/missing entries. Lots of stuff... > > Cheers! > -- Tracy Nelson > > =========================================================================== > 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".
