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.
We had built Object-to-Resource tools to interface PeopleSoft tables and 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. 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 4GL 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 create a "transactional" 4GL app, which would then allow you to intermix Message Definition calls with other database calls. 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".
