John Gagon who consulted developers on how to alter the code to use EJBs with DbForms finally reported that:

I have Session EJBs working with DBForms....I didn't change any source code to DBForms either.

What I did was within an interceptor. Lets say we have:

 

preInsert(HttpServletRequest request, DBFormsConfig config, Hashtable fieldValues, Connection con)
{
        
        //request and config stuff can go here.

        //jndi lookup...etc. 
        //(this could go in an abstract class that sandwiches between the dbforms interceptor
        //and your own)
        try
        {       

        fieldValues = beanInterface.doFunction(fieldValues, con);  
           //pass fieldValues for business logic.
           //shouldn't know about dbforms or request really. we want the beans to be interoperable.
           //the bean can have a flag that tells it whether to persist
           // or return persisance to the caller.
           //some utility beans can also convert the raw fieldValues to Beans 
           //and you can get dbforms apps to integrate with EJB apps...(kewl)
        
        }catch
        {
           //based on what is caught, you can ... rethrow ValidationExceptions, return DENY, 
           //throw blank ValidationExceptions(), log stuff, or simply decide to return GRANT anyway.
           //catch transactional exceptions, you could "recheck".
        }


}

In this way, the interceptors are thin adapters that can do little extra dbforms and web based work without doing a lot of business logic (like I used to do). The session bean does business work on the fieldValues and can work with other servers, track certain rules, calculate.

I think you can even do some transactional locking ie: between an inserts/selects and updates by throwing these exceptions or waiting "while(not_finished)"...of course, that can reduce performance. You could also session flag so that other interceptor methods cannot do that. (or you can put transactions in your database functions if your database supports it. (you could use the stateful session bean and declare a level of transactional thread safety on those session beans I think too)