Hi Thomas,

Hmmm, so it doesn't use updatable cursors.  So OJB is not recognizing that
an update has taken place.  When I call ODMG's Transaction.lock(obj,
Transaction.WRITE), how does it determine if an update has taken place?  In
my app, the servlet tier gets a Vector of O/R mapped objects from the EJB
tier, updates a given object, then calls the EJB tier updateObject() method
to update it.  Is there a problem with this?  I noticed in your ODMG
examples you explicitly lock an object before calling the update methods -
but I assumed it was different in an EJB-based app.

Q: is there a problem with this scenario?
*servlet app retrieves O/R mapped object via EJB layer (which uses ODMG),
but object is not locked (optimistic)
*servlet calls setter methods on the object
*servlet calls EJB updateObject method, which calls Transaction.lock

Q2: do I need to put an explicit READ lock on a retrieved list of objects
returned by the EJB tier?


Details:


Here is my app's architecture:

*OJB: uses the ODMG API w/in Jboss 3.2.1

*EJB tier: uses a PersistenceManagerBean SessionBean w/ insert, update,
delete methods; the implementation of the update methods are as follows

    /**
     * Store object that has been mapped in OJB repository
     * @param obj
     *
     * @ejb:interface-method
     */
    public Object updateObject(Object obj) throws DataAccessException {

        return storeObject(obj);
    }

    /**
     */
    public Object storeObject(Object obj) throws DataAccessException
    {
        try
        {
            if(log.isDebugEnabled()) log.debug("storeObject");

            Transaction tx = odmg.currentTransaction();
            tx.lock(obj, Transaction.WRITE);
        }
        catch (Throwable t)
        {
            t.printStackTrace();
            System.out.println(t.getMessage());
        }
        return obj;
    }

Here is the method used to retrieve a list for the servlet tier:
    /**
     * @ejb:interface-method
     */
    public Vector getVector(Class klass) throws DataAccessException {

        Vector result = null;
        try {

            OQLQuery query = odmg.newOQLQuery();
            query.create("select allObjects from " + klass.getName());
            DList list = (DList) query.execute();

            result = new Vector();
            Object[] vals = list.toArray();
            for (int i=0; i<list.size(); i++) {
                // Retrieve associated CLOB
                if (klass.newInstance() instanceof ClobVOInterface)
                {
                    ClobVOInterface vo = (ClobVOInterface)list.get(i);
                    retrieveClob((ClobVOInterface)vo);
                }

                result.add(list.get(i));
            }

        } catch (Throwable t) {
            t.printStackTrace();
        }

        return result;
    }

*DAO: 
DAO used by servlet tier to perform updates/retrieval (servlet doesn't
directly access PM), w/ following code:

public class DefaultDAO implements DAOInterface {

    public void updateVO(VOInterface obj) throws DataAccessException {
        PersistenceManagerRemote pm =
ServiceLocator.getInstance().getPersistenceManager();
        try {
            pm.updateObject(obj);
        } catch (DataAccessException e) {
            e.printStackTrace();
        } catch (RemoteException e) {
            e.printStackTrace();
        }
    }

    public Vector getAllVO(Class klass, ACL acl) throws DataAccessException
{
        PersistenceManagerRemote pm =
ServiceLocator.getInstance().getPersistenceManager();
        try {
            return pm.getVector(klass, acl);
        } catch (DataAccessException e) {
            e.printStackTrace();
        } catch (RemoteException e) {
            e.printStackTrace();
        }

        return null;
    }



*Servlet tier:
Uses DAO method to retrieve list of objects; then has edit form that allows
user to edit; here's the servlet update code 
        
          QueryVO query = (QueryVO)component;
        query.setLabel(validator.getUIValue("label"));
        query.setSql(validator.getUIValue("sql"));
        query.setMaxRows(validator.getUIValueAsInt("maxRows"));
 
query.setQueryTimeoutSecs(validator.getUIValueAsInt("queryTimeoutSecs"));

        DAOFactory.getDAO(DefaultDAO.class.getName()).updateVO(component,
acl);


-----Original Message-----
From: Thomas Mahler [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 07, 2003 11:08 PM
To: OJB Users List
Subject: Re: OJB uses jdbc cursor to Update - but my cursor doesn't support
up date!


Hi Alex

Bates, Alex wrote:
> Hello,
> 
> I've isolated the root cause of my problem.  But turning debugging on, 
> I saw all the SQL OJB was generating in my JBoss log file.
> 
> OJB generates SQL for SELECT and INSERT.  But for UPDATE, no SQL is 
> generated - it assumes it has an Updatable Cursor.  But my driver 
> cursor does not support update.

OJB does not use Updatable Cursors.
Using UC would mean to have a cursor  opened between read and the final 
broker.store() call. We don't do this to avoid problems with opened 
resources and because only a few JDBC drivers properly support this feature.

SO if there are no UPDATE statements generated it must be caused by 
something else.

are you using the ODMG API or the PB API?
Please provide the code section where you don't get UPDATES generated.

cheers,
Thomas

> 
> Q:  How do I tell OJB to use SQL to update instead of updating through 
> a Cursor?  I tried setting JDBC level to 1.0 in 
> repository_database.xml, but this didn't work.
> 
> Thanks in advance!
> 
> Alex
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to