I tried your fix after I debugged into the same problem.
My problem is, that I can invalidate the objects but after that there still no update is executed after next access
although ojb tells me:
[org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG:
executeUpdate :[EMAIL PROTECTED]
[org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG:
executeUpdate: [EMAIL PROTECTED]
For me it looks like the object is invalidated but not updated on next write.
I changed my write method to search for an existing object first and then invalidate it before I write the new one.
Is there anything wrong with that?
best regards,
Guido
Bates, Alex wrote:
Actually ended up just adding a proxy method to NarrowTransaction which maps down to the underlying TransactionImpl:
public void markDirty(Object anObject) {
if (tx instanceof TransactionImpl)
((TransactionImpl)tx).markDirty((anObject));
else
throw new UnsupportedOperationException("Not supported
operation"); }
-----Original Message-----
From: Bates, Alex Sent: Friday, August 08, 2003 2:31 PM
To: OJB Users List
Subject: RE: OJB uses jdbc cursor to Update - but my cursor doesn't suppor t
up date!
Thanks - In the meantime, how about this for a workaround:
I'll modify the NarrowTransaction class by adding a getter for its internal Transaction member, which is an instance of TransactionImpl - I'll use this getter in my code to retrieve the internal TransactionImpl, which I can then use to set the dirty flag -
Alex
-----Original Message-----
From: Michael Becke [mailto:[EMAIL PROTECTED] Sent: Friday, August 08, 2003 2:27 PM
To: OJB Users List
Subject: Re: OJB uses jdbc cursor to Update - but my cursor doesn't suppor t
up date!
I just submitted a bug (#OJB199) regarding this.
Mike
Bates, Alex wrote:
Okay, I tried a couple ways but I must be doing something wrong. I'mt
using rc4, and I'm getting a ClassCastException when I try to cast to TransactionImpl because the instance is actually a NarrowTransaction
14:16:36,217 INFO [STDOUT] query: yyyyyyyyyyyyyy select bonus;
14:16:36,217 INFO [STDOUT] tx: [EMAIL PROTECTED]
14:16:36,217 ERROR [STDERR] java.lang.ClassCastException
Any idea why the txn is a NarrowTransaction as opposed to a TransactionImpl, or how to change?
Thx,
Alex
-----Original Message-----
From: Bates, Alex
Sent: Friday, August 08, 2003 11:34 AM
To: OJB Users List
Subject: RE: OJB uses jdbc cursor to Update - but my cursor doesn't suppor
up date!t
Thanks Thomas! Will give this a try!
-----Original Message-----
From: Thomas Mahler [mailto:[EMAIL PROTECTED]
Sent: Friday, August 08, 2003 11:25 AM
To: OJB Users List
Subject: Re: OJB uses jdbc cursor to Update - but my cursor doesn't suppor
up date!
Hi Alex,
Bates, Alex wrote:
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?
Yes! ODMG has no notion of long transactions. that is ODMG want's you to perform all changes to object after locking them to the transactions.
So changing objects on the client, then sending them back to the server and locking them to a transaction will fail!
That's because the ODMG transaction manager was not able to track the state of that object.
The trick is as Follows:
After locking the changed object from the client call: ((o.a.ojb.odmg.TransactionImpl) tx).markDirty(instance);
*servlet app retrieves O/R mapped object via EJB layer (which usesYes, that would be another option. But it would mean to keep the ODMG
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?
tx
open during the client operations. And when the client returns the changes object you have to looup the proper transaction.
cheers, Thomas
Details:support
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
up date!feature.
Hi Alex
Bates, Alex wrote:
Hello,OJB does not use Updatable Cursors.
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.
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
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]
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
