Configurable SQL Statement generation
Hi,
I would like to generate to generate SQL select statements for DB2 in a managed
environment (JBoss). All Select Statements should be extended by for read
only. I found that it is possible to hardcode this at
org.apache.ojb.broker.accesslayer.sql.SqlSelectStatement
at
buildStatement()
There I added :
if(!hasParent())
{
stmt.append( FOR READ ONLY);
}
at the end where hasParent is another modification at
org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement
protected boolean hasParent()
{
return m_parentStatement==null?false:true;
}
This is for avoiding 'for read only' when the select statement is a sub
statement of an other sql statement. The clause can not be used in sub queries
like 'in ( select x from y)'.
This is working but is not very useable and it is platform dependent. So the
modified OJB Version won't work with other databases. I would like to implement
a better platform dependent solution. Is there a way to get the platform when
running in a managed environment? Is there a existing better way to implement
it or a better way to generate platform dependent SQL? The second thing is, why
m_parentStatement is set when executing selects by primary key during
insert/update statement execution? I found that these selects were not extended
and the reason was that m_parentStatement was set althoug the select statement
is not executed as sub select but as identity select.
Thanks in advance,
best regards,
Guido
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Configurable SQL Statement generation
Hi,
I would like to generate to generate SQL select statements for DB2 in a
managed environment (JBoss). All Select Statements should be extended by
for read only. I found that it is possible to hardcode this at
org.apache.ojb.broker.accesslayer.sql.SqlSelectStatement
at
buildStatement()
There I added :
if(!hasParent())
{
stmt.append( FOR READ ONLY);
}
at the end where hasParent is another modification at
org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement
protected boolean hasParent()
{
return m_parentStatement==null?false:true;
}
This is for avoiding 'for read only' when the select statement is a sub
statement of an other sql statement. The clause can not be used in sub
queries like 'in ( select x from y)'.
This is working but is not very useable and it is platform dependent. So the
modified OJB Version won't work with other databases. I would like to
implement a better platform dependent solution. Is there a way to get the
platform when running in a managed environment? Is there a existing better
way to implement it or a better way to generate platform dependent SQL? The
second thing is, why m_parentStatement is set when executing selects by
primary key during insert/update statement execution? I found that these
selects were not extended and the reason was that m_parentStatement was set
althoug the select statement is not executed as sub select but as identity
select.
Thanks in advance,
best regards,
Guido
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Query about more than one table
Hi Jakob, I am using OJB 1.0.4 but maybe that I did not change the repository.xml. You are right that I query for table_a. The resolve to A0 and A1 works for the A0.key=A1.key but not for the criteria. The crit.addEqualTo(key,new Integer(5)); crit.addEqualTo(table_b.otherfield,new Integer(10)); is correct and uses the attribute value instead of the column name? I will check for repository changes for OJB 1.0.4 at the documentation. Maybe that this might help. best regards, Guido Jakob Braeuchi wrote: hi guido, i assume that you query for instances of table_a. in this case ojb should resolve 'key' to 'A0.key' amd 'otherfield' to 'A1.otherfield'. what version of ojb are you using ? inverse-foreignkeyfield-id-ref looks rather old to me ? jakob Guido Beutler schrieb: Hi Jakob, here is a sample, I can not post the original code, sorry. what I am doing I now: crit.addEqualTo(key,new Integer(5)); crit.addEqualTo(table_b.otherfield,new Integer(10)); The problem now is, that key is a column in both table but thequery,which is build by OJB, adds select ... from table_a A0, table_bA1where A0.key=A1.key and key=5 and otherfield=10. The database(in mycase DB/2) reports a SQL error which says that key isambiguousbecause it is a field in table_a and table_b. In this case A0.key=5 would work. Best regards, Guido class-descriptorclass=table_a table=table_a object-cacheclass=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl/ field-descriptorid=1 name=key column=key jdbc-type=INTEGER primarykey=true autoincrement=false / !--whatever -- collection-descriptorname=table_belement-class-ref=table_bauto-retrieve=trueauto-update=falseauto-delete=false proxy=false refresh=true inverse-foreignkeyfield-id-ref=1/ /collection-descriptor /class-descriptor class-descriptorclass=table_b table=table_b object-cacheclass=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl/ field-descriptorid=1 name=key column=key jdbc-type=INTEGER primarykey=true autoincrement=false / !--whatever -- field-descriptorid=2 name=otherfield column=otherfield jdbc-type=INTEGER primarykey=true autoincrement=false / /class-descriptor No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.4.0/304 - Release Date: 07.04.2006 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Query about more than one table
Hi Jakob, here is a sample, I can not post the original code, sorry. what I am doing I now: crit.addEqualTo(key,new Integer(5)); crit.addEqualTo(table_b.otherfield,new Integer(10)); The problem now is, that key is a column in both table but the query,which is build by OJB, adds select ... from table_a A0, table_b A1where A0.key=A1.key and key=5 and otherfield=10. The database(in my case DB/2) reports a SQL error which says that key isambiguous because it is a field in table_a and table_b. In this case A0.key=5 would work. Best regards, Guido class-descriptorclass=table_a table=table_a object-cacheclass=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl/ field-descriptorid=1 name=key column=key jdbc-type=INTEGER primarykey=true autoincrement=false / !--whatever -- collection-descriptorname=table_b element-class-ref=table_bauto-retrieve=true auto-update=falseauto-delete=false proxy=false refresh=true inverse-foreignkeyfield-id-ref=1/ /collection-descriptor /class-descriptor class-descriptorclass=table_b table=table_b object-cacheclass=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl/ field-descriptorid=1 name=key column=key jdbc-type=INTEGER primarykey=true autoincrement=false / !--whatever -- field-descriptorid=2 name=otherfield column=otherfield jdbc-type=INTEGER primarykey=true autoincrement=false / /class-descriptor
Query about more than one table
Hi, I have a problem building query about more than one table when the field in a where clause with OJB 1.0.4 occur in more than one table with the same name. In SQL the following would work: select * from table_a A0, table_b A1 where A0.key=A1.key and A0.key=5 ; OJB builds a query where A0 and A! for the key ist correctly set. My Problem is at the Criteria where I would set: crit.addEqualTo(A0.key,key); This causes a NullPointer at broker.getCollectionByQuery(q); If I set the same without the A0 crit.addEqualTo(key,key); There is no NullPointer but a SQL Exception which tells me that key is ambiguous. How can I build queries like this? Thanks in advance, best regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
primary key field null after update
Hi, I am using OJB 1.0.4 inside of jboss 3.2.5. I updated from OJB 1.0.0 to 0.4 . Now I am running is a strange problem which did not occur in 1.0.0. When I update a object the primary key field is null after the store although the update is executed and succeed. The update sql statement is executed correctly, only the pk field at the value object is null after returning from ojb. When I insert a object of the same type with a null value at the primary ey field the sequence fills the field correctly and the primary key field at the object ist set correctly. The object has many references which have autoload and refresh set to true but auto update set to false. Has anybody seen this before? Thanks in advance, Guido
Change od Schema during Runtime
Hello, I would like to copy complex objects from schema A to schema B. This would run in a managed environment (JBoss EJB Server) The schema is configured at the XML Mapping, can I change this during runtime like 1) read data from schema A 2) change schema 3) store the same objects to schema B Is the change of the schema only for this transaction? Because the mapping configured at repository XML will be used by other transactions while the copy is running. best regards, Guido
Re: ArrayIndexOutOfBoundsException at 1:N relationship
Hi,
please forget all I wrote :)
I had a error at the definition of the pk of A. A second row was defined
as primary key too.
I think that I ran in this problem during my tests. This maybe why the
autoload was working
when I started. With the invalid pk definition the test case wouldn't
succeed
best regards,
Guido
[EMAIL PROTECTED] wrote:
Hi,
I have a problem with a java.lang.ArrayIndexOutOfBoundsException: 1
I have the following:
class A
{
Integer pkA
};
class B
{
Integer pkA // is PK
Integer pkB // is PK too
Integer otherField;
};
B has 2 primary key fields and A only one.
So the first field pkA of Class (and table ) B is the primary key of
Class (and table) A.
From point of view of A it is a 1:N relationship. I have a repository
with a collection descriptor at
A and a reference descriptor at B and both are working when I turn on
autoload.
I would like to query A and get all A where B.otherField=SomeValue.
This produces the ArrayIndexOutOfBoundsException. Can the problem be that
B has no own
pk field so that B.pkA is part of the primary key of the table B and part
of a reference descriptor
(and part of the collection descriptor of A) ?
best regards,
Guido
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Are sequence values incremented before use
Hi, I've got a strange problem when using sequences wir OJB 1.0.0. In some cases different applications get the same PK value but both are using the same sequence. Does OJB increment the sequence value before use? I configured the sequence at ojb as followed : sequence-manager className=org.apache.ojb.broker.util.sequence.SequenceManagerNextValImpl attribute attribute-name=autoNaming attribute-value=true/ /sequence-manager Is this correct? Thanks in advance. best regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Transaction rollback problem
Hi, I use OJB 1.0.0 inside of JBoss 3.2.3. how to handle the following condition: First I try to insert a row. This fails because of one required field wasn't filled and the transaction is rolled back. After that I try to insert the same row again, this time with correct data. OJB then generates a update statement instead of a insert statement and reports no kind of error. There are two things I don't understand: 1) why the objects are not removed from cache if the transaction is rolled back? Do I have to handle this and how? 2) why the SQL return code isn't checked for the number of updated rows. It would be possible to see in the return code that there was no row updated, so it is clear that the cache must have been invalid. Thanks in advance ab best regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JBoss have to close connection in managed environment and nes ted EJB calls
Hi,
I had the same problem with jboss 3.2.2 and different OJB versions.
The problem was solved at jboss 3.2.3. Armin may remember or long mail
threads. :-)
I haven't updated to 3.2.5 yet but for me it sounds as if the same problem
occurs there again. Could you make a quick check with 3.2.3 ?
best regards,
Guido
André Markwalder wrote:
Hi Armin,
Yes I did.
regards,
André
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: Freitag, 2. Juli 2004 14:25
To: OJB Users List
Subject: Re: JBoss have to close connection in managed environment and
nested EJB calls
Hi Andre,
do you set
PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFa
ctorySyncImpl
in OJB.properties?
regards,
Armin
André Markwalder wrote:
Hi,
I've got the following problem with OJB and JBoss in a managed
environment.
I do an EJB call to ejbA. Within that EJB I request a PersistenceBroker.
After
that request I call a second EJB. Let's call it ejbB. Within ejbB I
request
the same PersistenceBroker. After processing ejbB I release (close) the
PersistenceBroker. In ejbA I release (close) also the PersistenceBroker.
The problem is that JBoss informs me, that it has to close a connection
for
me and I should do it myself.
If I close the PersistenceBroker before I call ejbB and reobtain the
PersistenceBroker afterwards everything works fine.
It seems if I do a nested EJB call (nested retrieval of
PersistenceBroker),
OJB
doesn't close all the connections.
Did I something wrong or did I have misconfigured something within JBoss
or
OJB?
I configured OJB as described in the documentation (deployment section).
Below you will find the sample source code, JBoss log and OJB.properties
file.
I use JBoss 3.2.2 (tried also with 3.2.5 same effects) and OJB 1.0.0.
Thanks in advance for any help.
André
Sample source code from EJB:
/**
* @ejb.interface-method
* @ejb.permission role-name=admin,user
**/
public void test1() {
System.out.println(GETBROKER 1);
PersistenceBroker broker =
PersistenceBrokerFactoryFactory.instance().defaultPersistenceBroker();
try {
System.out.println(TEST1);
InitialContext ctx = new InitialContext();
AesUserLocalHome home =
(AesUserLocalHome)ctx.lookup(AesUserLocalHome.JNDI_NAME);
AesUserLocal tmp = home.create();
tmp.test2();
} catch (NamingException e) {
e.printStackTrace();
} catch (CreateException e) {
e.printStackTrace();
}
finally {
System.out.println(BROKER CLOSED 1);
if (broker != null) {
broker.close();
}
}
}
/**
* @ejb.interface-method
* @ejb.permission role-name=admin,user
**/
public void test2() {
System.out.println(GETBROKER 2);
PersistenceBroker broker =
PersistenceBrokerFactoryFactory.instance().defaultPersistenceBroker();
try {
System.out.println(TEST2);
}
finally {
System.out.println(BROKER CLOSED 2);
if (broker != null) {
broker.close();
}
}
}
JBOSS log:
13:58:16,232 DEBUG [PersistenceBrokerFactoryDefaultImpl] PersistenceBroker
pool will be setup with the following configuration
org.apache.commons.pool.impl.Gene
[EMAIL PROTECTED]
maxIdle=-1
maxActive=100
maxTotal=-1
maxWait=2000
whenExhaustedAction=0
testOnBorrow=false
testOnReturn=false
testWhileIdle=false
timeBetweenEvictionRunsMillis=-1
numTestsPerEvictionRun=10
minEvictableIdleTimeMillis=100
]
13:58:16,242 INFO [PersistenceBrokerFactoryDefaultImpl] Create
PersistenceBroker instance pool, pool configuration was
{whenExhaustedAction=0, maxIdle=-1, maxA
ctive=100, maxWait=2000, removeAbandoned=false, numTestsPerEvictionRun=10,
testWhileIdle=false, minEvictableIdleTimeMillis=100,
testOnReturn=false,
logAband
oned=false, removeAbandonedTimeout=300, timeBetweenEvictionRunsMillis=-1,
testOnBorrow=false}
13:58:16,262 INFO [STDOUT] GETBROKER 1
13:58:17,114 DEBUG [PersistenceBrokerFactoryDefaultImpl] Obtain broker
from
pool, used PBKey is org.apache.ojb.broker.PBKey: jcdAlias=APPSERVER_AES,
user=null,password=null
13:58:17,235 INFO [STDOUT] TEST1
13:58:17,235 INFO [STDOUT] GETBROKER 2
13:58:17,235 INFO [STDOUT] TEST2
13:58:17,235 INFO [STDOUT] BROKER CLOSED 2
13:58:17,235 DEBUG
[PersistenceBrokerFactorySyncImpl$PersistenceBrokerSyncImpl] PB close was
called, only close the PB handle when in JTA-tx
13:58:17,235 INFO [STDOUT] BROKER CLOSED 1
13:58:17,235 DEBUG
Re: Trying to return an unknown connection2!
Hi Armin, sorry for the delay! Because nobody else had an answer I spent some time to get closer to the problem. After that I posted my question at jboss. Here's the thread: http://www.jboss.org/index.html?module=bbop=viewtopict=49041 I don't know if I am allowed to repost the answer here (copyrights etc. ) Please use the link above. I'm curious about the replies here. best regards, Guido Armin Waibel wrote: Hi Guido, Any ideas what's going on there? I only answer to say No, I don't have a clue. I assume (maybe I'm completely wrong ;-)) that JBoss has problems in handling the connections/DataSources associated with the running tx in a proper way. Your direct connection instance will be associated with the suspended tx, within the new tx OJB lookup a new connection, do all work and close the connection. It seems that the used connection is not vaild in jboss TxConnectionManager...bla, bla Reached the line count for a do my best answer ;-) regards, Armin Guido Beutler wrote: Hello, I've got a strange problem with RC6 at JBoss 3.2.3. I've got a statefull and a stateless session bean. The stateless session bean contains all OJB stuff. The statefull facade accesses some tables via JDBC directly. That stateless session OJB bean has transaction attribute RequiresNew. The facade runs with Required. Both ejb's are container managed. If a method allocates a JDBC Connection from data source and then access the OJB EJB the following exception is thrown. java.lang.IllegalStateException: Trying to return an unknown connection2! [EMAIL PROTECTED] at org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterConnection(CachedConnectionManager.java:330) at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.connectionClosed(TxConnectionManager.java:539) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:296) at org.jboss.resource.adapter.jdbc.WrappedConnection.close(WrappedConnection.java:117) at org.apache.ojb.broker.util.WrappedConnection.close(WrappedConnection.java:124) at org.apache.ojb.broker.util.pooling.ByPassConnection.close(ByPassConnection.java:64) at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.releaseConnection(ConnectionFactoryAbstractImpl.java:79) at org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.releaseConnection(ConnectionManagerImpl.java:286) at org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl$PersistenceBrokerSyncImpl.beforeCompletion(PersistenceBrokerFactorySyncImpl.jav a:177) at org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl$TransactionBox.beforeCompletion(PersistenceBrokerFactorySyncImpl.java:329) at org.jboss.tm.TransactionImpl.doBeforeCompletion(TransactionImpl.java:1308) at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:347) at org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:398) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:325) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:118) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) at org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:331) at org.jboss.ejb.Container.invoke(Container.java:700) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546) at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:101) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:90) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:45) at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:100) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:85) I've got 2 workarounds. 1) If I change RequiresNew at the OJB EJB into Required the problem disappears. 2) If the facade does no access a JDBC connection the problem disappears too. Any ideas what's going on there? best regards, Guido
Re: Trying to return an unknown connection2!
Hi Armin, Armin Waibel wrote: Hi Guido, we can try to release the used connection on PB.close() call instead of Synchronization#beforeCompleation. For managed enviroment this seems to be better. ;-) Is it a difference or disadvantage for unmanaged enviroments? In PBFSyncImpl line 227 the close() method of PBImpl is overridden. If we are in local-tx we don't really close the used PB handle and thus do not release the used connection (it's done in #beforeCompleation). To do so we have to make PB.isInTransaction method independed from ConnectionManager.isInLocalTransaction method. After that we can release the used connection (via connectionManager) in PBSyncImpl.close method and keep PBSyncImpl still in PB-tx. Sounds like I have to take a look on it to understand what's to change. Currently I'm busy with other OJB stuff, but I will try this ASAP. Are you willing to test my changes or do you want to start this refactoring by your own? Of course I'm willing to test a fix. I'm currently a litte bit bussy too so impementing a fix on our own maybe difficult but I'll check it. thanks for the help and best regards, Guido regards, Armin Guido Beutler wrote: Hi Armin, sorry for the delay! Because nobody else had an answer I spent some time to get closer to the problem. After that I posted my question at jboss. Here's the thread: http://www.jboss.org/index.html?module=bbop=viewtopict=49041 I don't know if I am allowed to repost the answer here (copyrights etc. ) Please use the link above. I'm curious about the replies here. best regards, Guido Armin Waibel wrote: Hi Guido, Any ideas what's going on there? I only answer to say No, I don't have a clue. I assume (maybe I'm completely wrong ;-)) that JBoss has problems in handling the connections/DataSources associated with the running tx in a proper way. Your direct connection instance will be associated with the suspended tx, within the new tx OJB lookup a new connection, do all work and close the connection. It seems that the used connection is not vaild in jboss TxConnectionManager...bla, bla Reached the line count for a do my best answer ;-) regards, Armin Guido Beutler wrote: Hello, I've got a strange problem with RC6 at JBoss 3.2.3. I've got a statefull and a stateless session bean. The stateless session bean contains all OJB stuff. The statefull facade accesses some tables via JDBC directly. That stateless session OJB bean has transaction attribute RequiresNew. The facade runs with Required. Both ejb's are container managed. If a method allocates a JDBC Connection from data source and then access the OJB EJB the following exception is thrown. java.lang.IllegalStateException: Trying to return an unknown connection2! [EMAIL PROTECTED] at org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterConnection(CachedConnectionManager.java:330) at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.connectionClosed(TxConnectionManager.java:539) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:296) at org.jboss.resource.adapter.jdbc.WrappedConnection.close(WrappedConnection.java:117) at org.apache.ojb.broker.util.WrappedConnection.close(WrappedConnection.java:124) at org.apache.ojb.broker.util.pooling.ByPassConnection.close(ByPassConnection.java:64) at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.releaseConnection(ConnectionFactoryAbstractImpl.java:79) at org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.releaseConnection(ConnectionManagerImpl.java:286) at org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl$PersistenceBrokerSyncImpl.beforeCompletion(PersistenceBrokerFactorySyncImpl.jav a:177) at org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl$TransactionBox.beforeCompletion(PersistenceBrokerFactorySyncImpl.java:329) at org.jboss.tm.TransactionImpl.doBeforeCompletion(TransactionImpl.java:1308) at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:347) at org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:398) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:325) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:118) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) at org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:331) at org.jboss.ejb.Container.invoke(Container.java:700) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method
Trying to return an unknown connection2!
Hello, I've got a strange problem with RC6 at JBoss 3.2.3. I've got a statefull and a stateless session bean. The stateless session bean contains all OJB stuff. The statefull facade accesses some tables via JDBC directly. That stateless session OJB bean has transaction attribute RequiresNew. The facade runs with Required. Both ejb's are container managed. If a method allocates a JDBC Connection from data source and then access the OJB EJB the following exception is thrown. java.lang.IllegalStateException: Trying to return an unknown connection2! [EMAIL PROTECTED] at org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterConnection(CachedConnectionManager.java:330) at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.connectionClosed(TxConnectionManager.java:539) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:296) at org.jboss.resource.adapter.jdbc.WrappedConnection.close(WrappedConnection.java:117) at org.apache.ojb.broker.util.WrappedConnection.close(WrappedConnection.java:124) at org.apache.ojb.broker.util.pooling.ByPassConnection.close(ByPassConnection.java:64) at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.releaseConnection(ConnectionFactoryAbstractImpl.java:79) at org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.releaseConnection(ConnectionManagerImpl.java:286) at org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl$PersistenceBrokerSyncImpl.beforeCompletion(PersistenceBrokerFactorySyncImpl.jav a:177) at org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl$TransactionBox.beforeCompletion(PersistenceBrokerFactorySyncImpl.java:329) at org.jboss.tm.TransactionImpl.doBeforeCompletion(TransactionImpl.java:1308) at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:347) at org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:398) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:325) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:118) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) at org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:331) at org.jboss.ejb.Container.invoke(Container.java:700) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546) at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:101) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:90) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:45) at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:100) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:85) I've got 2 workarounds. 1) If I change RequiresNew at the OJB EJB into Required the problem disappears. 2) If the facade does no access a JDBC connection the problem disappears too. Any ideas what's going on there? best regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sequence Manager question
Hi Armin, Armin Waibel wrote: Hi, Guido Beutler wrote: NextValImpl is ok for me. There is a database sequence at the pk column which caused my problem. After setting the readonly attribute for the primary key column at the repository everything worked fine. hmm, this shouldn't work. If you set readonly the PK field will be not passed to the DB (and the PK will not be set). This only works for identity columns. ?? The database generates the pk value and permits that you can pass a pk value at a insert statement. Every insert statement, which contains the pk columns, causes a SQL Exception. This is the reason, why read-only works, I think. I had a db lock problem with db2 in former times when using NextValImpl but I think that is another problem. I never used DB2, so sorry I can't help. I havn't find a way to get the sequence name from db2 yet. So setting the name would currently not work. Without beeing able to access the db sequence the readonly attribute is the only choice. Why you need the sequence name from your database? If you set auto-naming=true in the sequence-manager descriptor, OJB will handle all sequence names for you. http://db.apache.org/ojb/sequencemanager.html#noAutoBuild If you want to use your own sequence names, you can declare them on field-descriptor level using the 'sequence-name' attribute. Maybe that I have another problem. I thought that OJB recognizes that a sequence (at database !) is defined for the column and would not generate inserts with pk columns in it. This seems not to be the case. Without read-only set at repository, OJB passes a pk with correct value but the statement failed because of the database sequence. best regards, Guido regards, Armin Thanks for the hint!! best regards, Guido regards, Armin Thomas Dudziak wrote: On Mon, 5 Apr 2004, Guido Beutler wrote: Hi Tom, Readonly was a usefull hint. I removed the sequence name at the class descriptor and added a readonly attribute. I still use nextVal sequence manager. This now works for me. Thanks !! I'm not sure that the sequence manager is used at all now. Please try the SequenceManagerNativeImpl to see whether it works too as it seems to me to be the more appropriate one in your case. Tom - 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]
Re: Sequence Manager question
Hi Tom, Thomas Dudziak wrote: On Tue, 6 Apr 2004, Guido Beutler wrote: Hi Armin, Armin Waibel wrote: Hi, Guido Beutler wrote: NextValImpl is ok for me. There is a database sequence at the pk column which caused my problem. After setting the readonly attribute for the primary key column at the repository everything worked fine. hmm, this shouldn't work. If you set readonly the PK field will be not passed to the DB (and the PK will not be set). This only works for identity columns. ?? The database generates the pk value and permits that you can pass a pk value at a insert statement. Every insert statement, which contains the pk columns, causes a SQL Exception. This is the reason, why read-only works, I think. If the database (as opposed to OJB) automatically creates the pk value upon insertion of a new row, then you should indeed use the NativeImpl as this is what it's designed for. Can I choose the sequence implementation per class? There are only a few tables which uses DB sequences. For all other tables the NextValImpl is ok. The problem is that only a few tables use DB sequences. You should be aware that db-generated pk-values do not work in OJB when you have an inheritance hierarchy that is mapped onto multiple tables, e.g. B extends A and A mapped to TABLE_A, B mapped to TABLE_B. In this case you should let OJB insert the pk values using your sequence and the NextValImpl. Otherwise you get problems for instance when trying to retrieve all objects of type A. Currently there are no derived classes for that table but I'll keep it in mind, thanks for the hint. best regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Sequence Manager question
Hi, I use OJB RC6 and DB2. I want to insert a abject into a table with a sequence. I took the settings from documentation and added to database.xml : sequence-manager className=org.apache.ojb.broker.util.sequence.SequenceManagerNextValImpl attribute attribute-name=autoNaming attribute-value=true/ /sequence-manager and at the class descriptor : primarykey=true autoincrement=true sequence-name=TEST_SEQUENCE OJB still tries to insert the pk field to which causes a SQL exception. DB2 expects that the field is not used at the insert statement. DB2 then generates the pk value itself. I also tried to leave the sequence name open but this had no effect. What am I doing wrong? best regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sequence Manager question
Hi Tom, Thomas Dudziak wrote: On Mon, 5 Apr 2004, Guido Beutler wrote: Hi, I use OJB RC6 and DB2. I want to insert a abject into a table with a sequence. I took the settings from documentation and added to database.xml : sequence-manager className=org.apache.ojb.broker.util.sequence.SequenceManagerNextValImpl attribute attribute-name=autoNaming attribute-value=true/ /sequence-manager and at the class descriptor : primarykey=true autoincrement=true sequence-name=TEST_SEQUENCE OJB still tries to insert the pk field to which causes a SQL exception. DB2 expects that the field is not used at the insert statement. DB2 then generates the pk value itself. I also tried to leave the sequence name open but this had no effect. What am I doing wrong? How is the field defined in the database ? I'm no expert on sequence managers, but as far as I understand them, the difference between SequenceManagerNextValImpl and SequenceManagerNativeImpl is that for the former, in the database the field is defined as a normal field (no autoincrement/identity setting) whereas for the native impl the database increments the field automatically (without OJB intervening, thus you should have access='readonly' in this case). Tom Readonly was a usefull hint. I removed the sequence name at the class descriptor and added a readonly attribute. I still use nextVal sequence manager. This now works for me. Thanks !! best regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configuration problem with rc6
Hello, i've got a small howto question. I use PB API of OJB RC6 inside of JBoss 3.2.3 with DB2. There are applications which directly access the same data without usng OJB or ejb. My problem now is that I would like to lock some (not all) objects imediately. Normaly I use read uncommited but at EJB's the data are written at commit of the whole transaction what means other apps can modify the data until the ejb transaction is commited. I would like to lock the objects (again, not all) for other reads like repeatable read. Is it possible to do this only for some objects? Where to set the jdbc transaction isolation in general when usin ojb with ejb's? best regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Transaction isolation OJB inside EJB's
Hello, i've got a small howto question. I use PB API of OJB RC6 inside of JBoss 3.2.3 with DB2. There are applications which directly access the same data without usng OJB or ejb. My problem now is that I would like to lock some (not all) objects imediately. Normaly I use read uncommited but at EJB's the data are written at commit of the whole transaction what means other apps can modify the data until the ejb transaction is commited. I would like to lock the objects (again, not all) for other reads like repeatable read. Is it possible to do this only for some objects? Where to set the jdbc transaction isolation in general when usin ojb with ejb's? best regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configuration problem with rc6
Sorry wrong header Guido Beutler wrote: Hello, i've got a small howto question. I use PB API of OJB RC6 inside of JBoss 3.2.3 with DB2. There are applications which directly access the same data without usng OJB or ejb. My problem now is that I would like to lock some (not all) objects imediately. Normaly I use read uncommited but at EJB's the data are written at commit of the whole transaction what means other apps can modify the data until the ejb transaction is commited. I would like to lock the objects (again, not all) for other reads like repeatable read. Is it possible to do this only for some objects? Where to set the jdbc transaction isolation in general when usin ojb with ejb's? best regards, Guido - 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]
Re: Null Value generated if auto-retrieve set to false
Hi Armin, works great. Thanks very much :-) As you could see from my mail I started moving from primitives to objects. Your performance argument for 1:n is a very strong one. The null value problem was a side effect of my work. best regards, Guido Armin Waibel wrote: Hi Guido, Guido Beutler wrote: Hello, I set the auto-retrieve attribute at repository to false for a 1:1 relationship. I need the reference for a query but in most cases I do not want to read the referenced object. After reading a instance I tried to store the same unmodified object again. I run into a SQL error during the update statement can not write null into not null field. After some debugging I realized that the missing field is the FK field of not materialized 1:1 reference object. We do a refactoring of the auto-xxx settings to prevent this problem. In your case set auto-update=none instead of false. Please see http://db.apache.org/ojb/tutorial3.html#1:1%20auto-xxx%20setting If you want to use auto-update=object or true, then you have to load the reference first, see http://db.apache.org/ojb/tutorial3.html#auto-retrieve%20setting Does this solve you problem? By the way, in rc6 is bug when set auto-delete=false, OJB interpret it as true, so better use none. It's fixed in CVS. regards, Armin If I remove the reference descriptor from the mapping everything works fine, but my queries won't work. For me it looks like storing an object when auto-retrieve is set to false fails. I expected that ojb recognize that the auto-retrieve attribute was set to false and then takes the fk attribute field for the update and not the reference which may be null (because not retrieved). The fk field is of type Integer. The integer Object is filled with the correct value. Any idea? best regards, Guido - 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]
Re: Insert instead of update generated in RC6
Hi Armin, Armin Waibel wrote: Hi again, all ejb-example tests pass (odmg- and PB-Tests) on JBoss 3.2.2 and MaxDB. Maybe I forget to write a test for object update ;-). Do you remember our DataSource problem with 3.2.2.RC3 with missing results? Maybe that the behavior is different to JBoss 3.2.3., just to have is said. :-) Does ist help? I can not see your Methods at the stack trace. Is it possible, that the cache is never checked? You can't see one of these methods in your stack trace, bacause these methods maybe generate a wrong value for boolean 'doInsert' in your case. The change made between rc5 to rc6 is a new check serviceBrokerHelper().hasNullPKField(cld, obj); and the deletedDuringTransaction.contains(oid); check. Is it possible that you pass a nullified PK field (declared in decriptor) when you update an object? In that case OJB try to insert the object. I think you have two possibilities: - remote debugging of this part of PBImpl class to see if a wrong boolean value was set - signals insert instead of update. - Put some System.out.println to check the boolean or/and comment out the new stuff and see what's going on. I reduced my test to get some objects at a collection and store the same objects again (without any modification). The test immediately fails at the first insert. Because the select returns the expected result and the objects are returned by OJB I think I can be sure that the objects are filled correctly. I'll add some code to store the values before returning them to the client but I don't think that this will make any difference. best regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Insert instead of update generated in RC6
Hi again, Guido Beutler wrote: Hi Armin, Armin Waibel wrote: Hi again, all ejb-example tests pass (odmg- and PB-Tests) on JBoss 3.2.2 and MaxDB. Maybe I forget to write a test for object update ;-). Do you remember our DataSource problem with 3.2.2.RC3 with missing results? Maybe that the behavior is different to JBoss 3.2.3., just to have is said. :-) Does ist help? I can not see your Methods at the stack trace. Is it possible, that the cache is never checked? You can't see one of these methods in your stack trace, bacause these methods maybe generate a wrong value for boolean 'doInsert' in your case. The change made between rc5 to rc6 is a new check serviceBrokerHelper().hasNullPKField(cld, obj); and the deletedDuringTransaction.contains(oid); check. Is it possible that you pass a nullified PK field (declared in decriptor) when you update an object? In that case OJB try to insert the object. I think you have two possibilities: - remote debugging of this part of PBImpl class to see if a wrong boolean value was set - signals insert instead of update. - Put some System.out.println to check the boolean or/and comment out the new stuff and see what's going on. I reduced my test to get some objects at a collection and store the same objects again (without any modification). The test immediately fails at the first insert. Because the select returns the expected result and the objects are returned by OJB I think I can be sure that the objects are filled correctly. I'll add some code to store the values before returning them to the client but I don't think that this will make any difference. If I select a collection by OJB and store ist at the same EJB Method (and transaction) a insert instead of update is generated. The PK Fields are filled correctly and are not modified during the test. best regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Insert instead of update generated in RC6
Armin Waibel wrote: do you use anonymous keys? If so where? Do you remember our DataSource problem with 3.2.2.RC3 with missing results? No, can you describe this problem again? Should I update to JBoss 3.2.3 and run the tests again? we had the problem, that not all objects were returned by OJB. This seemed to be a side effect of the eager-release flag. After Update to JBoss 3.2.3 the problem disapeared. Maybe that the bahavior of our current problem is different in 3.2.3. I'll put some debug gcode into PersistenceBroker and see what's going on during insert/update. best regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Insert instead of update generated in RC6
Guido Beutler wrote:
Armin Waibel wrote:
do you use anonymous keys? If so where?
Do you remember our DataSource problem with 3.2.2.RC3 with missing
results?
No, can you describe this problem again? Should I update to JBoss
3.2.3 and run the tests again?
we had the problem, that not all objects were returned by OJB. This
seemed to be a side effect of the eager-release
flag. After Update to JBoss 3.2.3 the problem disapeared. Maybe that
the bahavior of our current problem is different
in 3.2.3.
I'll put some debug gcode into PersistenceBroker and see what's going
on during insert/update.
best regards,
Guido
Hi,
I added some debug code to
PersistenceBrokerImpl :
public void store(Object obj) throws PersistenceBrokerException
{
...
boolean doInsert = serviceBrokerHelper().hasNullPKField(cld,
obj);
returns true. The reason seems to be BrokerHelper.representsNull :
public boolean representsNull(FieldDescriptor fld, Object aValue)
{
.
if(((aValue instanceof Number) (((Number) aValue).longValue()
== 0)))
{
result = fld.getPersistentField().getType().isPrimitive()
fld.isPrimaryKey();
}
return result;
}
returns true for my SMALLINT objects if the value is 0. But 0 is a
leagal value for SMALLINT PK attributes.
After that PersistenceBrokerImpl.store checks the cache:
/*
if PK values are set, lookup cache or db to see whether object
needs insert or update
*/
if (!doInsert)
{
doInsert = objectCache.lookup(oid) == null
!serviceBrokerHelper().doesExist(cld, oid, obj);
}
because of doInsert is still true (I checked it) The cache is never
checked for the object. doInsert is still true and
a few lines later
// now store it:
store(obj, oid, cld, doInsert);
generates the insert statement. Maybe I'm wrong but for me it looks like
a 0 (not null) at any PK field causes a insert statement.
In my case it is immediately the first object. Is it a good idea to
check the cache independent if doInsert is true or is the implementation
of representsNull the cause and should be changed ?
best regards,
Guido
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Insert instead of update generated in RC6
Hi,
changing
public boolean representsNull(FieldDescriptor fld, Object aValue)
{
.
if(((aValue instanceof Number) (((Number) aValue).longValue()
== 0)))
{
result = fld.getPersistentField().getType().isPrimitive()
fld.isPrimaryKey();
}
return result;
}
into
result = fld.getPersistentField().getType().isPrimitive() !
fld.isPrimaryKey();
seems to fix my problem, updates are generated now and insert's work too.
One of our OJB Guru's like Armin should take a look on it. ;-)
I just made some small tests and can not be sure that this don't produce
some side effects.
If my fix is correct, updates never worked for objects with 0 values at
primary key fields.
best regards,
Guido
Guido Beutler wrote:
Guido Beutler wrote:
Armin Waibel wrote:
do you use anonymous keys? If so where?
Do you remember our DataSource problem with 3.2.2.RC3 with missing
results?
No, can you describe this problem again? Should I update to JBoss
3.2.3 and run the tests again?
we had the problem, that not all objects were returned by OJB. This
seemed to be a side effect of the eager-release
flag. After Update to JBoss 3.2.3 the problem disapeared. Maybe that
the bahavior of our current problem is different
in 3.2.3.
I'll put some debug gcode into PersistenceBroker and see what's going
on during insert/update.
best regards,
Guido
Hi,
I added some debug code to
PersistenceBrokerImpl :
public void store(Object obj) throws PersistenceBrokerException
{
...
boolean doInsert =
serviceBrokerHelper().hasNullPKField(cld, obj);
returns true. The reason seems to be BrokerHelper.representsNull :
public boolean representsNull(FieldDescriptor fld, Object aValue)
{
.
if(((aValue instanceof Number) (((Number)
aValue).longValue() == 0)))
{
result = fld.getPersistentField().getType().isPrimitive()
fld.isPrimaryKey();
}
return result;
}
returns true for my SMALLINT objects if the value is 0. But 0 is a
leagal value for SMALLINT PK attributes.
After that PersistenceBrokerImpl.store checks the cache:
/*
if PK values are set, lookup cache or db to see whether object
needs insert or update
*/
if (!doInsert)
{
doInsert = objectCache.lookup(oid) == null
!serviceBrokerHelper().doesExist(cld, oid, obj);
}
because of doInsert is still true (I checked it) The cache is never
checked for the object. doInsert is still true and
a few lines later
// now store it:
store(obj, oid, cld, doInsert);
generates the insert statement. Maybe I'm wrong but for me it looks
like a 0 (not null) at any PK field causes a insert statement.
In my case it is immediately the first object. Is it a good idea to
check the cache independent if doInsert is true or is the implementation
of representsNull the cause and should be changed ?
best regards,
Guido
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Insert instead of update generated in RC6
Hi,
Edson Carlos Ericksson Richter wrote:
Let me make some comments:
Using primitive, then there is no other way to specify a nullability.
I think we can take to the developer a choice to use nullable and
primitive int but keep it always warned that 0 will save NULL in the
database, and a NULL in database will, in turn, be converted to a 0 in
primitive field. I think a WARN in docs is sufficient.
At repository_user.xml I can define attributes like:
field-descriptor id=1
name=col
column=col
jdbc-type=INTEGER
conversion=org.apache.ojb.broker.accesslayer.conversions.Int2IntegerFieldConversion
/
I think this is the correct way to tell OJB if 0 should represent null
or not. The behavior to handle int 0 values as null values
is new in RC6. In RC5 OJB stored a 0 if no aditional conversion was defined.
Maybe a future nullable attribute in field-descritor could help,
with values zeroIsNull, negativeIsNull, false, true (where
false means default action: 0 == 0, -1 == -1, and true means actual
behaviour 0==null. The other options talk by itself).
I think the conversion always solves the problem but of course this
would work too.
But in PK, that doesn't allow NULL, if the primitive field is 0 we can
have two situations: if the mapping tell us that there is an
auto-increment field, then user doesn't want a real 0, but a newly
inserted field. Auto-increments, as far as I have seen don't use 0 as
starting point.
I think using autoincrement isn't as clear as a nullable attribute or
conversion.
comment type=maybe_offtopicAs interesting history, some weeks ago
a beginner developer asked me about a product type codes: 0 - Service,
1 - Resale product, 2 - Own factoried product. I said to him: never,
ever, use 0 as PK to avoid problems for understanding. In meantime,
another begginer at his side said 0, in my point of view, is expected
to means nothing, so I'll never use it as value for a PK. I'm tending
to agree with this vision./comment
If the table has only one pk field I would agree with that but there may
be tables with several pk fields. I don't think that defining
don't use 0 in pk fields is a general rule for those tables.
So, OJB could test if the field is auto-increment, and, if true, then
assume that it's a new record being inserted. If false, assume that
it's a 0 since there is no NULLs in PKs, and should be a update if
already exists. This change, as far as I can see, will not change the
current behaviour of OJB, right?
Would work, but I still don't understand why not using conversion.
best regards,
Guido
Just my 2 cents,
Edson Richter
Armin Waibel wrote:
Guido Beutler wrote:
Hi,
changing
public boolean representsNull(FieldDescriptor fld, Object aValue)
{
.
if(((aValue instanceof Number) (((Number)
aValue).longValue() == 0)))
{
result =
fld.getPersistentField().getType().isPrimitive() fld.isPrimaryKey();
}
return result;
}
into
result = fld.getPersistentField().getType().isPrimitive() !
fld.isPrimaryKey();
seems to fix my
problem, updates are generated now and insert's work too.
One of our OJB Guru's like Armin should take a look on it. ;-)
I just made some small tests and can not be sure that this don't
produce some side effects.
If my fix is correct, updates never worked for objects with 0 values
at primary key fields.
Maybe I'm on the wrong tack, but I don't figure out the change. This
method should return 'true'
- when the field as number of '0'
- and the field is primitive (short in your case)
- and the field-descriptor is declared as PK
In your patch you return true, when the field was not declared as PK.
But in that case all values are valid ('0' too). Your patch do the
opposite from what I expected. Maybe I'm completely confused ;-)
Again, if you have a class with primitive short field, declared as PK
with value '0', OJB assume that the field is nullified and because PK
couldn't be 'null' OJB assume the given object was new.
Hope I don't make a fool of oneself ;-)
regards,
Armin
best regards,
Guido
Guido Beutler wrote:
Guido Beutler wrote:
Armin Waibel wrote:
do you use anonymous keys? If so where?
Do you remember our DataSource problem with 3.2.2.RC3 with
missing
results?
No, can you describe this problem again? Should I update to JBoss
3.2.3 and run the tests again?
we had the problem, that not all objects were returned by OJB.
This seemed to be a side effect of the eager-release
flag. After Update to JBoss 3.2.3 the problem disapeared. Maybe
that the bahavior of our current problem is different
in 3.2.3.
I'll put some debug gcode into PersistenceBroker and see what's
going on during insert/update.
best regards,
Guido
Hi,
I added some debug code to
PersistenceBrokerImpl :
public void store(Object obj) throws PersistenceBrokerException
{
...
boolean doInsert
Re: Insert instead of update generated in RC6
Armin Waibel wrote:
Guido Beutler wrote:
Hi,
changing
public boolean representsNull(FieldDescriptor fld, Object aValue)
{
.
if(((aValue instanceof Number) (((Number)
aValue).longValue() == 0)))
{
result =
fld.getPersistentField().getType().isPrimitive() fld.isPrimaryKey();
}
return result;
}
into
result = fld.getPersistentField().getType().isPrimitive() !
fld.isPrimaryKey();
seems to fix my problem,
updates are generated now and insert's work too.
One of our OJB Guru's like Armin should take a look on it. ;-)
I just made some small tests and can not be sure that this don't
produce some side effects.
If my fix is correct, updates never worked for objects with 0 values
at primary key fields.
Maybe I'm on the wrong tack, but I don't figure out the change. This
method should return 'true'
- when the field as number of '0'
- and the field is primitive (short in your case)
- and the field-descriptor is declared as PK
Yes and I think the second is not correct. 0 at primary key's,
especially if the column is only one of a set of pk columns,
is a legal value, maybe that I'm wrong of course. I like using primitive
fields at my data classes, because they are fast,
small and I can avoid converting everything from int to Integer and back
again. Of course this is only one (my) opinion.
In your patch you return true, when the field was not declared as PK.
But in that case all values are valid ('0' too). Your patch do the
opposite from what I expected. Maybe I'm completely confused ;-)
You're right, this is nonsens. :-)
Throwing away the rule would work for me too.
Again, if you have a class with primitive short field, declared as PK
with value '0', OJB assume that the field is nullified and because PK
couldn't be 'null' OJB assume the given object was new.
At repository_user.xml I can define attributes like:
field-descriptor id=1
name=col
column=col
jdbc-type=INTEGER
conversion=org.apache.ojb.broker.accesslayer.conversions.Int2IntegerFieldConversion
/
I thought, this is legal for PK fields too. Am I wrong with that?
The behavior to handle int 0 values as null values is new in RC6. In RC5
OJB stored a 0 if no additional conversion was defined.
I thought that the additional conversion was build to handle exact this
behavior.
In relational databases 0 is a legal pk value too and may exist in many
databases. Why restrict this when using OJB ?
Edson is right with his suggestion, that testing for auto-increment
would solve my problem too,
but I still don't understand why it is necessary to test for 0 in
primitive types. If I define a primitive type and don't
add a special conversion I documented at the repository that I know that
0 is treated as 0 (like in RC5 ).
Maybe that I documented that this is a bad mapping too :-)
I thought using primitive types means that you can never write a null
value. In my current application I can live with that
and prefer to use the performance improvement of primitives. In other
applications other mappings are better.
best regards,
Guido
Hope I don't make a fool of oneself ;-)
regards,
Armin
best regards,
Guido
Guido Beutler wrote:
Guido Beutler wrote:
Armin Waibel wrote:
do you use anonymous keys? If so where?
Do you remember our DataSource problem with 3.2.2.RC3 with missing
results?
No, can you describe this problem again? Should I update to JBoss
3.2.3 and run the tests again?
we had the problem, that not all objects were returned by OJB. This
seemed to be a side effect of the eager-release
flag. After Update to JBoss 3.2.3 the problem disapeared. Maybe
that the bahavior of our current problem is different
in 3.2.3.
I'll put some debug gcode into PersistenceBroker and see what's
going on during insert/update.
best regards,
Guido
Hi,
I added some debug code to
PersistenceBrokerImpl :
public void store(Object obj) throws PersistenceBrokerException
{
...
boolean doInsert =
serviceBrokerHelper().hasNullPKField(cld, obj);
returns true. The reason seems to be BrokerHelper.representsNull :
public boolean representsNull(FieldDescriptor fld, Object aValue)
{
.
if(((aValue instanceof Number) (((Number)
aValue).longValue() == 0)))
{
result = fld.getPersistentField().getType().isPrimitive()
fld.isPrimaryKey();
}
return result;
}
returns true for my SMALLINT objects if the value is 0. But 0 is a
leagal value for SMALLINT PK attributes.
After that PersistenceBrokerImpl.store checks the cache:
/*
if PK values are set, lookup cache or db to see whether
object
needs insert or update
*/
if (!doInsert)
{
doInsert = objectCache.lookup(oid) == null
!serviceBrokerHelper().doesExist(cld, oid, obj);
}
because of doInsert
Insert instead of update generated in RC6
Hello, I updated from RC5 to RC6. I am using OJB inside of JBoss 3.2.3 with DB2 V8. Since update to RC6 OJB generates a insert for every stored object when using PB API. OJB seems not to check if the object exists at database. If the object already exist, a SQL Exception is thrown. (-803 which means dublicated PK). If I try to insert the same object several times, every time the same exception is thrown. If I select the object first, OJB generates a insert too. I tried the same with RC5 (just to be sure that it is not a error at the test case) and RC5 works as expected. If the object exist a update is generated. Did I miss something or is it a new issue? best regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Insert instead of update generated in RC6
Armin Waibel wrote:
Hi Guido,
Guido Beutler wrote:
Hello,
I updated from RC5 to RC6. I am using OJB inside of JBoss 3.2.3 with
DB2 V8.
Since update to RC6 OJB generates a insert for every stored object
when using PB API.
OJB seems not to check if the object exists at database. If the
object already exist,
a SQL Exception is thrown. (-803 which means dublicated PK). If I try
to insert the same object
several times, every time the same exception is thrown. If I select
the object first, OJB generates a insert too.
I tried the same with RC5 (just to be sure that it is not a error at
the test case) and RC5 works as expected.
If the object exist a update is generated.
Did I miss something or is it a new issue?
hmm, in PBImpl we do:
ClassDescriptor cld = getClassDescriptor(obj.getClass());
/*
if one of the PK fields was null, the objects was new
and needs insert
*/
boolean doInsert = serviceBrokerHelper().hasNullPKField(cld, obj);
//if one of the PK field represents 'null' OJB assume the object is new
Identity oid = new Identity(obj, this, cld);
/*
if the object has been deleted during this transaction,
then we must insert it
*/
boolean shouldRemoveFromDeleted = false;
if (!doInsert)
{
doInsert = deletedDuringTransaction.contains(oid);
shouldRemoveFromDeleted = true;
}
/*
if PK values are set, lookup cache or db to see whether object
needs insert or update
*/
if (!doInsert)
{
doInsert = objectCache.lookup(oid) == null
!serviceBrokerHelper().doesExist(cld, oid, obj);
}
// now store it:
store(obj, oid, cld, doInsert);
Which of these methods returns a wrong result?
regards,
Armin
Hi Armin, :-)
that's the stacktrace:
org.apache.ojb.broker.PersistenceBrokerSQLException: SQL failure while
insert object data for class
...
at
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeInsert(JdbcAccessImpl.java:242)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(PersistenceBrokerImpl.java:1620)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:1537)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:683)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(DelegatingPersistenceBroker.java:174)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(DelegatingPersistenceBroker.java:174)
And here's the Cache related stuff from ojb.properties:
#
# Object cache
#
# The ObjectCacheClass entry tells OJB which concrete ObjectCache
# implementation is to be used as standard cache.
# Its also possible to override this entry adding object-cache elements
# on jdbc-connection-descriptor level and
# per class-descriptor in repository file. More info see documentation.
#
ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerBrokerImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheJCSPerClassImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerClassImpl
#
#
# This property is only relevant if the per class-descriptor object-cache
# declaration was used in conjunction with metadata runtime changes.
# If set 'flase' the class name of the object is used
# to find a per class ObjectCache implementation.
# If set 'true' the ObjectCacheDescriptor instance is used as key to
# find a per class ObjectCache, this enables to use different ObjectCache
# instances for the same class.
descriptorBasedCaches=false
#
#
# Use CacheFilters to do filter operations before caching methods were
# called. Build your own filter class by implementing
org.apache.ojb.cache.CacheFilter.
# It is possible to use a arbitrary number of CacheFilters, but this slows
# down the performance of the cache, thus handle with care.
#
# - org.apache.ojb.broker.cache.CacheFilterClassImpl
# allows filtering of classes
# - org.apache.ojb.broker.cache.CacheFilterPackageImpl
# allows filtering of packages
# More info see Javadoc of the according classes.
# Set a comma separated list of CacheFilter.
#ObjectCacheFilter=org.apache.ojb.broker.cache.CacheFilterClassImpl,org.apache.ojb.broker.cache.CacheFilterPackageImpl
#
Does ist help? I can not see your Methods at the stack trace. Is it
possible, that the cache is never checked?
best regards,
Guido
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Mapping two classes two one table
Hi, I've got a small problem. I have a table with many columns. I would like to select only the primary key field with a complex select first. It's like a candidate list. From that I can find the correct value (independen from the database). For the correct value I would like to receive all data. I build two classes and mapped them to the same table. This is working fine. I got one class only with the primary key and another with all fields. I do not use inheritance, because all entries of the table have the same type (there is no third class with another type). The problem now is , that during the select for the primary key class OJB creates a select for all colums although only the primary key is needed. This is working, the primary key class is filled correctly. The the reason for building a primary key class was the performance impact of reading all coloumns. I would like to avoid reading all colums if I need only one. Is there a way to avoid reading all coulums directly? best regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mapping two classes two one table
Hi jakob, Thanks for the fast reply! works fine but one shot question: How do I get the values (colums) from the object ? At the test cases I found only asserts on the size of the collection. Of course I would like to get the values. Thanks in Advance!! best regards, Guido Jakob Braeuchi wrote: hi guido, use a report-query to retrieve the pks only. hth jakob Guido Beutler wrote: Hi, I've got a small problem. I have a table with many columns. I would like to select only the primary key field with a complex select first. It's like a candidate list. From that I can find the correct value (independen from the database). For the correct value I would like to receive all data. I build two classes and mapped them to the same table. This is working fine. I got one class only with the primary key and another with all fields. I do not use inheritance, because all entries of the table have the same type (there is no third class with another type). The problem now is , that during the select for the primary key class OJB creates a select for all colums although only the primary key is needed. This is working, the primary key class is filled correctly. The the reason for building a primary key class was the performance impact of reading all coloumns. I would like to avoid reading all colums if I need only one. Is there a way to avoid reading all coulums directly? best regards, Guido - 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]
Re: How to restrict result of 1:N mappings
Hi Jakob,
ok, first QueryCustomizer implementation is working :-)
Thanks!
Now I got the next question. How should I pass values on the fly to my
customizer.
I would like to restrict the collection to one value and at my test case
I already have the
primary key of the row. But how can I pass this value to my customizer?
I saw that I could add attributes at the deployment descriptor but the
value of the
primary key changes dynamically during my application.
My sample:
public Query customizeQuery(Object anObject, PersistenceBroker
aBroker, CollectionDescriptor aCod, QueryByCriteria aQuery)
{
aQuery.getCriteria().addEqualTo(field,value);
return aQuery;
}
The value should change dynamically. Could somebody give me a
aditional hint?
best regards,
Guido
Jakob Braeuchi wrote:
hi guido,
please have a look at the query customizer.
jakob
Guido Beutler wrote:
Hello,
I've got a 1:N mapping between classes. I would like to restrict the
entries at the retrieved collection.
I got two Classes A and B with a 1:n mapping between it. B has 17000
entries so I would like
to restrict the collection to a small set of B's by using the primary
key of B.
By using a path expression I get the correct A but the collection
from A to B contains all values of B
not only the ones with the given b.pk .
Could somebody give me a hint where to look at?
Thanks in advance, best regards,
Guido
-
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]
How to pass dynamic attribute values to QueryCustomizer Implementations
Hello,
This is a repost with a better subject, hoping to get a hint.
I build a custom QueryCustomizer implementation to restrict the
retrieved values of a collection to a known primary key.
I saw that I could add attributes at the deployment descriptor but the
value of the
primary key changes dynamically during my application.
My sample:
public Query customizeQuery(Object anObject, PersistenceBroker
aBroker, CollectionDescriptor aCod, QueryByCriteria aQuery)
{
aQuery.getCriteria().addEqualTo(field,value);
return aQuery;
}
The value should change dynamically. Is there really no way to pass
additional dynamic arguments to the implementation?
IA Simple workaround is to use System properties but of course this just
a hack for a test case. It's not thread save, it's slow
etc.
I found no way to find out where the current query came from to build
sonething like a callback. Extending the Query implementation by
a user object would be a solution buit this modification shouldn't be
done without consulting the OJB crew.
Implementing a user object might be difficult because the querry which
is passed to the QueryCustomizer is generated by OJB and is
not directly coming from my code. So a modified Query would mean that
the user object must be passed around by OJB Broker.
I still think that I miss something.
best regards,
Guido
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to pass dynamic attribute values to QueryCustomizer Implementations
Hello,
I'm a bit restricted in posting original code but I'll do my best :-)
Ok.
Brian McCallister wrote:
Saw your original message and am thinking about this one.
Any chance you can post specifics?
Does value need to change while running, or is it just dependent upon
something at load time?
at runtime and that is the main problem. During load time I could solve
by using the attributes at the repository.
I have two classes A and B and A has a 1:n relationshop to B.
class-descriptor class=A table=A
field-descriptor id=1
name=a_key
column=a_key
jdbc-type=INTEGER
/
collection-descriptor name=b_col element-class-ref=B
auto-retrieve=true auto-update=false auto-delete=false
proxy=false refresh=false
inverse-foreignkey field-id-ref=2/
query-customizer
class=QueryCustomizerFilterImpl
attribute
attribute-name=attr1
attribute-value=value1
/
/query-customizer
/collection-descriptor
/class-descriptor
class-descriptor class=B table=B
field-descriptor id=1
name=b_key
column=b_key
jdbc-type=INTEGER
primarykey=true
autoincrement=false
/
field-descriptor id=2
name=a_key
column=a_key
jdbc-type=INTEGER
primarykey=true
autoincrement=false
/
/class-descriptor
Criteria crit = new Criteria();
crit.addEqualTo(key, value1);
Criteria crit2 = new Criteria();
crit2.addEqualTo(b_col.b_key, pk_value_of_B);
Criteria crit3 = new Criteria();
crit3.addAndCriteria(crit);
crit3.addAndCriteria(crit2);
Query q = QueryFactory.newQuery(A.class, crit3);
Collection results = broker.getCollectionByQuery(q);
I would like to get a collection a.b_col which contains only the
elements of B which has the primary key pk_value_of_B not ALL
values. The query from above gives the correct instance of A but the
collection is filled with all existing b which are very much.
So I build a QueryCustomizer where I can add the missing select criteria
to the query which was build from OJB to load ALL b.
public Query customizeQuery(Object anObject, PersistenceBroker
aBroker, CollectionDescriptor aCod, QueryByCriteria aQuery)
{
aQuery.getCriteria().addEqualTo(b_key,pk_value_of_B);
return aQuery;
}
My problem is how to get the pk_value_of_B to the QueryCustomizer
instance. The QueryCustomizer instance is constructed by OJB
so the default constructor is called, no way to pass a argument with my
pk value. After that OJB calls the customizeQuery method and again
it looks like there is no way to get my key in there.
Hope this is more readable and a bit more detailed.
best regards,
Guido
-Brian
On Fri, 2003-12-19 at 10:09, Guido Beutler wrote:
Hello,
This is a repost with a better subject, hoping to get a hint.
I build a custom QueryCustomizer implementation to restrict the
retrieved values of a collection to a known primary key.
I saw that I could add attributes at the deployment descriptor but the
value of the
primary key changes dynamically during my application.
My sample:
public Query customizeQuery(Object anObject, PersistenceBroker
aBroker, CollectionDescriptor aCod, QueryByCriteria aQuery)
{
aQuery.getCriteria().addEqualTo(field,value);
return aQuery;
}
The value should change dynamically. Is there really no way to pass
additional dynamic arguments to the implementation?
IA Simple workaround is to use System properties but of course this just
a hack for a test case. It's not thread save, it's slow
etc.
I found no way to find out where the current query came from to build
sonething like a callback. Extending the Query implementation by
a user object would be a solution buit this modification shouldn't be
done without consulting the OJB crew.
Implementing a user object might be difficult because the querry which
is passed to the QueryCustomizer is generated by OJB and is
not directly coming from my code. So a modified Query would mean that
the user object must be passed around by OJB Broker.
I still think that I miss something.
best regards,
Guido
-
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]
Re: How to pass dynamic attribute values to QueryCustomizerImplementations
Hello,
for a more detailed description pleas look at my other mail.
Daniel Perry wrote:
I am still confused by this too.
sorry!
Say i have a 1:n mapping between Manager and Employee.
I want to query using ODMG to say
select all Managers (and their Employees) where Manager.department=blah AND
Employee.status=fulltime
OK then you get a filled collection with all fulltime Employee in there.
I did this using a query customizer for static queries (eg
Employee.deleted=false).
I never worked out how to do dynamicly though. My (bodge) solution was to
load the Managers with all their Employees, and then remove any Employees
from the collection that didnt match my criteria.
You're right but lets say youre loading 17000 Employees, this may tke a
while ;-)
I already know that I would need only 1 to 5 so removing them would work
but not really is a solution (in my case).
I can see an obvious problem with this querying - if you materialise a
Manager, all Employees relating to it should be materialised, as say for
example you do a markDirty on the Manager object matching the above
criteria, all the Employees not matching status=fulltime would not be in the
collection when it's written, so would be lost.
Still, for read only (eg web interfaces like JSP using taglibs) it would be
very useful to be able to do these queries.
Yes, I'm only doing selects and for performance of my application this
would be _very_ usefull.
For me OJB needs 30s to build the collection
best regards,
Gudio
Daniel.
- Original Message -
From: Brian McCallister [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Sent: Friday, December 19, 2003 3:27 PM
Subject: Re: How to pass dynamic attribute values to
QueryCustomizerImplementations
Saw your original message and am thinking about this one.
Any chance you can post specifics?
Does value need to change while running, or is it just dependent upon
something at load time?
-Brian
On Fri, 2003-12-19 at 10:09, Guido Beutler wrote:
Hello,
This is a repost with a better subject, hoping to get a hint.
I build a custom QueryCustomizer implementation to restrict the
retrieved values of a collection to a known primary key.
I saw that I could add attributes at the deployment descriptor but the
value of the
primary key changes dynamically during my application.
My sample:
public Query customizeQuery(Object anObject, PersistenceBroker
aBroker, CollectionDescriptor aCod, QueryByCriteria aQuery)
{
aQuery.getCriteria().addEqualTo(field,value);
return aQuery;
}
The value should change dynamically. Is there really no way to pass
additional dynamic arguments to the implementation?
IA Simple workaround is to use System properties but of course this just
a hack for a test case. It's not thread save, it's slow
etc.
I found no way to find out where the current query came from to build
sonething like a callback. Extending the Query implementation by
a user object would be a solution buit this modification shouldn't be
done without consulting the OJB crew.
Implementing a user object might be difficult because the querry which
is passed to the QueryCustomizer is generated by OJB and is
not directly coming from my code. So a modified Query would mean that
the user object must be passed around by OJB Broker.
I still think that I miss something.
best regards,
Guido
-
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]
Re: How to pass dynamic attribute values to QueryCustomizer Implementations
Hi,
Lance Eason wrote:
It's entirely possible to do this, but in general I think it's a bad design *to* do it.
I never said that it is the best way to do it. :-)
Collection descriptors are used to model relationships, not arbitrary dynamic queries. The role of query customizers is to allow you to statically refine the relationship to make it more specific than just foreign-key/primary-key. What you're attempting to do is to abuse the mechanism to make it a dynamic query mechanism which isn't the intention. As a result I think you'll find a lot of subtle problems pop up if you go down this route, the first being caching (e.g. what happens when the parent item you're retrieving is answered from the cache and already has a collection that was customized dynamically from the last time it was used). What I really think you want to do here is expose you're dynamic queries off of accessors you write yourself rather than trying to wedge them into collection descriptors. Something like:
class-descriptor class=Foo table=Foo
field-descriptor id=1
name=fooKey
column=foo_key
jdbc-type=INTEGER
/
/class-descriptor
class-descriptor class=Bar table=Bar
field-descriptor id=1
name=barKey
column=bar_key
jdbc-type=INTEGER
primarykey=true
autoincrement=false
/
field-descriptor id=2
name=fooKey
column=foo_key
jdbc-type=INTEGER
primarykey=true
autoincrement=false
/
/class-descriptor
public class A
{
private Integer fooKey;
public Collection getBarsByKey(int barKey)
{
Criteria crit = new Criteria();
crit.addEqualTo(fooKey, fooKey);
crit.addEqualTo(barKey, barKey);
Query q = QueryFactory.newQuery(Bar.class, crit);
Collection results = broker.getCollectionByQuery(q);
}
}
As an added bonus you don't have to play any tricks to get your dynamic information down to a query customizer, the dynamic information simply comes in as attributes on the method invocation.
If you insist on doing it the other way, the traditional way to pass arguments past an interface that doesn't support it is to use ThreadLocal but I really think you would be better served by reconsidering your design.
You're right, that your solution would work. The other point of view ist
that you have to write aditional code, the getBarsByKey method.
Of course this is more flexible than using a fixed class. Maybe
dependent of the application which way is the better one.
I'll check what your solution would mean for my application.
Thanks, it's really another point of view.
best regards,
Guido
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to pass dynamic attribute values to QueryCustomizerImplementations
Daniel Perry wrote:
Sorry, i didn't mean i was confused by your mail, i mean i am in the same
boat!
Are you using ODMG or PB or JDO?
PB
I believe that using PB (and the example i gave before) you can do somthing
like:
Criteria crit = new Criteria();
crit.addLike(department, blah);
crit.addLike(employees.status, fulltime)
Query qry = new QueryByCriteria(Manager.class, crit);
Could you use somthing like this to query on the collection?
Build an or criteria with things like:
crit.addEquals(employees.oid, id1)
crit.addEquals(employees.oid, id2)
crit.addEquals(employees.oid, id3)
How would you do this same query using ODMG? or even, can you do this with
ODMG?
No because the ODMB implementation of OJB doesn't support the path like
queries.
I tried things like
where department=$1 and employee.status=$2
but it didnt work.
Yes won't works see: http://db.apache.org/ojb/status.html
best regards,
Guido
Daniel.
- Original Message -
From: Guido Beutler [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Sent: Friday, December 19, 2003 4:07 PM
Subject: Re: How to pass dynamic attribute values to
QueryCustomizerImplementations
Hello,
for a more detailed description pleas look at my other mail.
Daniel Perry wrote:
I am still confused by this too.
sorry!
Say i have a 1:n mapping between Manager and Employee.
I want to query using ODMG to say
select all Managers (and their Employees) where Manager.department=blah
AND
Employee.status=fulltime
OK then you get a filled collection with all fulltime Employee in there.
I did this using a query customizer for static queries (eg
Employee.deleted=false).
I never worked out how to do dynamicly though. My (bodge) solution was
to
load the Managers with all their Employees, and then remove any Employees
from the collection that didnt match my criteria.
You're right but lets say youre loading 17000 Employees, this may tke a
while ;-)
I already know that I would need only 1 to 5 so removing them would work
but not really is a solution (in my case).
I can see an obvious problem with this querying - if you materialise a
Manager, all Employees relating to it should be materialised, as say for
example you do a markDirty on the Manager object matching the above
criteria, all the Employees not matching status=fulltime would not be in
the
collection when it's written, so would be lost.
Still, for read only (eg web interfaces like JSP using taglibs) it would
be
very useful to be able to do these queries.
Yes, I'm only doing selects and for performance of my application this
would be _very_ usefull.
For me OJB needs 30s to build the collection
best regards,
Gudio
Daniel.
- Original Message -
From: Brian McCallister [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Sent: Friday, December 19, 2003 3:27 PM
Subject: Re: How to pass dynamic attribute values to
QueryCustomizerImplementations
Saw your original message and am thinking about this one.
Any chance you can post specifics?
Does value need to change while running, or is it just dependent upon
something at load time?
-Brian
On Fri, 2003-12-19 at 10:09, Guido Beutler wrote:
Hello,
This is a repost with a better subject, hoping to get a hint.
I build a custom QueryCustomizer implementation to restrict the
retrieved values of a collection to a known primary key.
I saw that I could add attributes at the deployment descriptor but the
value of the
primary key changes dynamically during my application.
My sample:
public Query customizeQuery(Object anObject, PersistenceBroker
aBroker, CollectionDescriptor aCod, QueryByCriteria aQuery)
{
aQuery.getCriteria().addEqualTo(field,value);
return aQuery;
}
The value should change dynamically. Is there really no way to pass
additional dynamic arguments to the implementation?
IA Simple workaround is to use System properties but of course this
just
a hack for a test case. It's not thread save, it's slow
etc.
I found no way to find out where the current query came from to build
sonething like a callback. Extending the Query implementation by
a user object would be a solution buit this modification shouldn't be
done without consulting the OJB crew.
Implementing a user object might be difficult because the querry which
is passed to the QueryCustomizer is generated by OJB and is
not directly coming from my code. So a modified Query would mean that
the user object must be passed around by OJB Broker.
I still think that I miss something.
best regards,
Guido
-
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
Order of field-descriptor id entries at repository
Hello, I had some stange values aut objects since updated to RC5. After some debuging I found out that I got illegal values at attributes which does not match with the database. For example I got a attribute at tahe object with the value 15 where a 0 is stored at the corresponding database row. The solution was the sort order at the repository_user.xml. My repository_user.xml was auto generated and did not represent the correct order of field-descriptor id's. I former time this worked. Now it seems that the id's must have the correct order. After sorting the repository everything worked fine. All the fields had the correct id so it was not a real mapping error. I just thougt that OJB uses the field-descriptor for mapping the column. I'll now sort my repository an think that everything will work after that. Will this problem be fixed? I thing trusting in the position is dangerous. best regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to restrict result of 1:N mappings
Hello, I've got a 1:N mapping between classes. I would like to restrict the entries at the retrieved collection. I got two Classes A and B with a 1:n mapping between it. B has 17000 entries so I would like to restrict the collection to a small set of B's by using the primary key of B. By using a path expression I get the correct A but the collection from A to B contains all values of B not only the ones with the given b.pk . Could somebody give me a hint where to look at? Thanks in advance, best regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB RC4 does not select all objects?
Hi Armin,
just another hint, maybe you already know this..
During testing for possible workarounds I ran into a test case for a class
without any relationship to other classes (no references, no foreign
keys no inheritance,
as flat as it could be).
This test case works with eager-release=true without any problem.
Maybe that the problem only occours if complex objects has to be build
by OJB.
Could you (or somebody else) find out anything that helps?
Oh and you posted a sample from JBoss 3.2..1. I'm running with JBoss
3.2.2RC3
I don't know if this makes a difference for the current problem.
best regards,
Guido
Armin Waibel wrote:
Hi Guido,
On Thu, 09 Oct 2003 15:17:24 +0200, Guido Beutler
[EMAIL PROTECTED] wrote:
Hi Armin,
just to keep the problem clear:
If I run my standalone tescase (without any jboss around it) and set
eager-release to true the problem occours too!
Only one instead of 77 objects are selected.
If I change to eager-release=false all 77 objects are selected.
clear, that's why we should kick 'eager-release' out.
eager-release is a work-around that does not really work.
So we should try to solve the main problem, occur when
run jboss with eager-release 'false' setting.
regards,
Armin
best regards,
Guido
Armin Waibel wrote:
Hi Guido,
On Wed, 08 Oct 2003 18:17:21 +0200, Guido Beutler
[EMAIL PROTECTED] wrote:
Hi Armin,
took some time but I was able to build the testcase.
snip :-)
great!
...
If I run the standalone testcase with eager-release=true
the test fails. Only one object is selected.
If I set eager-release=false everything works fine.
eager-release is the root of all evil :-)
I know it's a workaround for a jboss problem.
What can I do inside of jboss with my ejb's now???
I don't know if this problem is caused by
jboss or by OJB. But I assume it's jboss because
I never heard about problems (with connections) within
e.g. weblogic.
The 'eager-release' attribute was introduced by
Matthew, maybe he can sheed some light on the
problem why jboss needs this special handling.
you said when set eager-release 'false' you get the
following stack trace:
15:59:17,408 INFO [TxConnectionManager$TxConnectionEventListener]
throwable from unregister connection
java.lang.IllegalStateException: Trying to return an unknown
connection1! [EMAIL PROTECTED]
at
org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterConnection(CachedConnectionManager.java:264)
at
org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.connectionClosed(TxConnectionManager.java:550)
...
I looked in the source code of jboss 3.2.1
online source can be found at
http://threebit.net/documentation/doxygen/jboss-3.2.1-src/html/CachedConnectionManager_8java-source.html
http://threebit.net/documentation/doxygen/jboss-3.2.1-src/html/TxConnectionManager_8java-source.html
TxConnectionManager$TxConnectionEventListener.connectionClosed looks
like
public void connectionClosed(ConnectionEvent ce)
00541 {
00542 log.trace(connectionClosed called);
00543 if (this.getManagedConnection() !=
(ManagedConnection)ce.getSource())
00544 {
00545 throw new
IllegalArgumentException(ConnectionClosed event received from wrong
ManagedConnection! Expected: + this.getManagedConnection() + ,
actual: + ce.getSource());
00546 } // end of if ()
00547 //log.trace(about to call unregisterConnection);
00548 try
00549 {
00550
getCcm().unregisterConnection(TxConnectionManager.this,
ce.getConnectionHandle()); }
00551 catch (Throwable t)
00552 {
00553 log.info(throwable from unregister connection, t);
00554 } // end of try-catch
00555
...
and CachedConnectionManager.unregisterConnection looks like
00248void unregisterConnection(ConnectionCacheListener cm,
Object c)
00249{
00250 KeyConnectionAssociation key = peekMetaAwareObject();
00251 if (log.isTraceEnabled())
00252 {
00253 log.trace(unregistering connection from + cm + ,
object: + c + , key: + key);
00254 } // end of if ()
00255 if (key == null)
00256 {
00257 return; //not participating properly in this
management scheme.
00258 } // end of if ()
00259
00260 Map cmToConnectionsMap = key.getCMToConnectionsMap();
00261 Collection conns = (Collection)cmToConnectionsMap.get(cm);
00262 if (conns == null)
00263 {
00264 throw new IllegalStateException(Trying to return an
unknown connection1! + c);
00265 //return;//???shouldn't happen.
00266 } // end of if ()
00267 for (Iterator i = conns.iterator(); i.hasNext(); )
00268 {
00269 if (((ConnectionRecord)i.next()).connection == c)
...
Looks strange for me to throw an IllegalStateException and then
catch it and log with info-level.
Next strange server log output (when run bean examples) is something
like
Re: OJB RC4 does not select all objects?
Hi Armin,
just to keep the problem clear:
If I run my standalone tescase (without any jboss around it) and set
eager-release to true the problem occours too!
Only one instead of 77 objects are selected.
If I change to eager-release=false all 77 objects are selected.
best regards,
Guido
Armin Waibel wrote:
Hi Guido,
On Wed, 08 Oct 2003 18:17:21 +0200, Guido Beutler
[EMAIL PROTECTED] wrote:
Hi Armin,
took some time but I was able to build the testcase.
snip :-)
great!
...
If I run the standalone testcase with eager-release=true
the test fails. Only one object is selected.
If I set eager-release=false everything works fine.
eager-release is the root of all evil :-)
I know it's a workaround for a jboss problem.
What can I do inside of jboss with my ejb's now???
I don't know if this problem is caused by
jboss or by OJB. But I assume it's jboss because
I never heard about problems (with connections) within
e.g. weblogic.
The 'eager-release' attribute was introduced by
Matthew, maybe he can sheed some light on the
problem why jboss needs this special handling.
you said when set eager-release 'false' you get the
following stack trace:
15:59:17,408 INFO [TxConnectionManager$TxConnectionEventListener]
throwable from unregister connection
java.lang.IllegalStateException: Trying to return an unknown
connection1! [EMAIL PROTECTED]
at
org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterConnection(CachedConnectionManager.java:264)
at
org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.connectionClosed(TxConnectionManager.java:550)
...
I looked in the source code of jboss 3.2.1
online source can be found at
http://threebit.net/documentation/doxygen/jboss-3.2.1-src/html/CachedConnectionManager_8java-source.html
http://threebit.net/documentation/doxygen/jboss-3.2.1-src/html/TxConnectionManager_8java-source.html
TxConnectionManager$TxConnectionEventListener.connectionClosed looks
like
public void connectionClosed(ConnectionEvent ce)
00541 {
00542 log.trace(connectionClosed called);
00543 if (this.getManagedConnection() !=
(ManagedConnection)ce.getSource())
00544 {
00545 throw new IllegalArgumentException(ConnectionClosed
event received from wrong ManagedConnection! Expected: +
this.getManagedConnection() + , actual: + ce.getSource());
00546 } // end of if ()
00547 //log.trace(about to call unregisterConnection);
00548 try
00549 {
00550
getCcm().unregisterConnection(TxConnectionManager.this,
ce.getConnectionHandle()); }
00551 catch (Throwable t)
00552 {
00553 log.info(throwable from unregister connection, t);
00554 } // end of try-catch
00555
...
and CachedConnectionManager.unregisterConnection looks like
00248void unregisterConnection(ConnectionCacheListener cm, Object c)
00249{
00250 KeyConnectionAssociation key = peekMetaAwareObject();
00251 if (log.isTraceEnabled())
00252 {
00253 log.trace(unregistering connection from + cm + ,
object: + c + , key: + key);
00254 } // end of if ()
00255 if (key == null)
00256 {
00257 return; //not participating properly in this management
scheme.
00258 } // end of if ()
00259
00260 Map cmToConnectionsMap = key.getCMToConnectionsMap();
00261 Collection conns = (Collection)cmToConnectionsMap.get(cm);
00262 if (conns == null)
00263 {
00264 throw new IllegalStateException(Trying to return an
unknown connection1! + c);
00265 //return;//???shouldn't happen.
00266 } // end of if ()
00267 for (Iterator i = conns.iterator(); i.hasNext(); )
00268 {
00269 if (((ConnectionRecord)i.next()).connection == c)
...
Looks strange for me to throw an IllegalStateException and then
catch it and log with info-level.
Next strange server log output (when run bean examples) is something
like:
2003-10-08 23:22:07,782 DEBUG
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl]
SQL:INSERT INTO EJB_ARTICLE
(ARTICLE_ID,NAME,PRICE,DESCRIPTION,CATEGORY_ID) VALUES (?,?,?,?,?)
2003-10-08 23:22:07,782 DEBUG
[org.apache.ojb.broker.accesslayer.JdbcAccessImpl] executeInsert:
[EMAIL PROTECTED]
2003-10-08 23:22:07,782 DEBUG
[org.apache.ojb.broker.accesslayer.StatementManager] closeResources
was called
2003-10-08 23:22:07,782 DEBUG
[org.apache.ojb.broker.core.PersistenceBrokerImpl] PB.close was
called: [EMAIL PROTECTED]
2003-10-08 23:22:07,782 WARN
[org.jboss.resource.adapter.jdbc.WrappedConnection] Closing a
statement you left open, please do your own housekeeping
That's strange, because StatementManager close given statement on
'closeResources' call.
Does OJB internally open another statement and do not close, or do
jboss ignore
the statement close call made by StatementManager?
Any kind of proposal are welcome!
regards
Re: OJB RC4 does not select all objects?
Hi Armin, first thanks for your support !! Armin Waibel wrote: Hi Guido, sorry for the late reply! On Mon, 06 Oct 2003 09:37:26 +0200, Guido Beutler [EMAIL PROTECTED] wrote: Hi again, because I did not get any reply for my postings I'm trying to get some information. What mean side effect? when set eager-releas='true' the connection was closed after each statement in StatementManager was closed. But as long as the datasource is not exceeded getting a nex connection shoudn't be a problem. If the datasource limit is reached I get exceptions that ojb couldn't obtain a new connection. In this case no exception is thrown. I'm running inside of jboss and without eager-releas='true' the datasource extends it's maximum limit. That's the reason why eager-release was introduced ;-) I remember that :-) Why not all objects are selected and why without throwing any exception? Is there a workaround (instead of making a lot of primary key selects)? as I said in my previous post this can be a side-effect of eager-release, but I'm not sure. Did your test case pass in OJB standalone mode? If yes, the problem is eager-release. Ok. I'll build a standalone test case and try it out. best regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB RC4 does not select all objects?
Hi Armin, took some time but I was able to build the testcase. snip :-) Why not all objects are selected and why without throwing any exception? Is there a workaround (instead of making a lot of primary key selects)? as I said in my previous post this can be a side-effect of eager-release, but I'm not sure. Did your test case pass in OJB standalone mode? If yes, the problem is eager-release. If I run the standalone testcase with eager-release=true the test fails. Only one object is selected. If I set eager-release=false everything works fine. eager-release is the root of all evil :-) I know it's a workaround for a jboss problem. What can I do inside of jboss with my ejb's now??? best regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB RC4 does not select all objects?
Hi again, because I did not get any reply for my postings I'm trying to get some information. What mean side effect? I'm running inside of jboss and without eager-releas='true' the datasource extends it's maximum limit. Why not all objects are selected and why without throwing any exception? Is there a workaround (instead of making a lot of primary key selects)? best regards, Guido Armin Waibel wrote: Hi Guido, this can be a side-effect of the eager-release attribute when set 'true'. Did you tried to run your test with 'false'? Or is your test successful in standalone OJB? regards, Armin - Original Message - From: Guido Beutler [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 3:27 PM Subject: Re: OJB RC4 does not select all objects? Hi,, I tried a workaround and select all A by a loop with direct primary key access like: select allobject from A where key=$1 Whith this select I get all expected objects but of course this is not very comfortable to code a loop for every IN clause. best regards, Guido Original Message Subject: OJB RC4 does not select all objects? Date: Wed, 01 Oct 2003 14:20:15 +0200 From: Guido Beutler [EMAIL PROTECTED] To: OJB Users List [EMAIL PROTECTED] Hello, I've got a strange problem. I have two Tables A and B with corresponding classes. B has a foreign key to A and so I have a 1:N between A and B. A has a reference-descriptor to B and B has a collection-descriptor to A. If I try to select all instances of A i only get a few entries instead of 20. If I reinvoke the test case the number of retrieved objects raises until 20 is reached. select allobject from A where key is in ($1) $1 is a collection of 20 integers. If I select all objects of B first and then select all A i get the expected 20 objects. In both cases no exception is thrown. I'm using rc4 with ODMG inside of JBoss 3.2.2. with DB/2. Has anybody seen this before? gest regards, Guido - 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]
Re: OJB RC4 does not select all objects?
Hi again, if turning off eager-release=false I get the following Exception: 15:59:17,301 INFO [STDOUT] [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: 15:59:17,302 INFO [STDOUT] executeQuery: [EMAIL PROTECTED] 15:59:17,408 INFO [TxConnectionManager$TxConnectionEventListener] throwable from unregister connection java.lang.IllegalStateException: Trying to return an unknown connection1! [EMAIL PROTECTED] at org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterConnection(CachedConnectionManager.java:264) at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.connectionClosed(TxConnectionManager.java:550) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:287) at org.jboss.resource.adapter.jdbc.WrappedConnection.close(WrappedConnection.java:127) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.resource.connectionmanager.CachedConnectionManager.closeAll(CachedConnectionManager.java:375) at org.jboss.resource.connectionmanager.CachedConnectionManager.popMetaAwareObject(CachedConnectionManager.java:199) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:190) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:72) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:267) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:118) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) at org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:331) at org.jboss.ejb.Container.invoke(Container.java:700) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) What's that?? Seems that OJB creates a connection instead using the data source? best regards, Guido Guido Beutler wrote: Hi Armin, :-) yes I'm using eager-release = 'true' with 'false' my connection pool die's when running under load :-( I'll try 'false' just for a test and post the result. Do you mean that I can not trust select results if running with 'true'? best regards, Guido Armin Waibel wrote: Hi Guido, this can be a side-effect of the eager-release attribute when set 'true'. Did you tried to run your test with 'false'? Or is your test successful in standalone OJB? regards, Armin - Original Message - From: Guido Beutler [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 3:27 PM Subject: Re: OJB RC4 does not select all objects? Hi,, I tried a workaround and select all A by a loop with direct primary key access like: select allobject from A where key=$1 Whith this select I get all expected objects but of course this is not very comfortable to code a loop for every IN clause. best regards, Guido Original Message Subject: OJB RC4 does not select all objects? Date: Wed, 01 Oct 2003 14:20:15 +0200 From: Guido Beutler [EMAIL PROTECTED] To: OJB Users List [EMAIL PROTECTED] Hello, I've got a strange problem. I have two Tables A and B with corresponding classes. B has a foreign key to A and so I have a 1:N between A and B. A has a reference-descriptor to B and B has a collection-descriptor to A. If I try to select all instances of A i only get a few entries instead of 20. If I reinvoke the test case the number of retrieved objects raises until 20 is reached. select allobject from A where key is in ($1) $1 is a collection of 20 integers. If I select all objects of B first and then select all A i get the expected 20 objects. In both cases no exception is thrown. I'm using rc4 with ODMG inside of JBoss 3.2.2. with DB/2. Has anybody seen this before? gest regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL
Re: OJB RC4 does not select all objects?
Hi,, I tried a workaround and select all A by a loop with direct primary key access like: select allobject from A where key=$1 Whith this select I get all expected objects but of course this is not very comfortable to code a loop for every IN clause. best regards, Guido Original Message Subject:OJB RC4 does not select all objects? Date: Wed, 01 Oct 2003 14:20:15 +0200 From: Guido Beutler [EMAIL PROTECTED] To: OJB Users List [EMAIL PROTECTED] Hello, I've got a strange problem. I have two Tables A and B with corresponding classes. B has a foreign key to A and so I have a 1:N between A and B. A has a reference-descriptor to B and B has a collection-descriptor to A. If I try to select all instances of A i only get a few entries instead of 20. If I reinvoke the test case the number of retrieved objects raises until 20 is reached. select allobject from A where key is in ($1) $1 is a collection of 20 integers. If I select all objects of B first and then select all A i get the expected 20 objects. In both cases no exception is thrown. I'm using rc4 with ODMG inside of JBoss 3.2.2. with DB/2. Has anybody seen this before? gest regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
OJB RC4 does not select all objects?
Hello, I've got a strange problem. I have two Tables A and B with corresponding classes. B has a foreign key to A and so I have a 1:N between A and B. A has a reference-descriptor to B and B has a collection-descriptor to A. If I try to select all instances of A i only get a few entries instead of 20. If I reinvoke the test case the number of retrieved objects raises until 20 is reached. select allobject from A where key is in ($1) $1 is a collection of 20 integers. If I select all objects of B first and then select all A i get the expected 20 objects. In both cases no exception is thrown. I'm using rc4 with ODMG inside of JBoss 3.2.2. with DB/2. Has anybody seen this before? gest regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
OJB RC4 does not select all objects?
Hello, I've got a strange problem. I have two Tables A and B with corresponding classes. B has a foreign key to A and so I have a 1:N between A and B. A has a reference-descriptor to B and B has a collection-descriptor to A. If I try to select all instances of A i only get a few entries instead of 20. If I reinvoke the test case the number of retrieved objects raises until 20 is reached. select allobject from A where key is in ($1) $1 is a collection of 20 integers. If I select all objects of B first and then select all A i get the expected 20 objects. In both cases no exception is thrown. I'm using rc4 with ODMG inside of JBoss 3.2.2. with DB/2. Has anybody seen this before? gest regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB RC4 does not select all objects?
Hi Armin, :-) yes I'm using eager-release = 'true' with 'false' my connection pool die's when running under load :-( I'll try 'false' just for a test and post the result. Do you mean that I can not trust select results if running with 'true'? best regards, Guido Armin Waibel wrote: Hi Guido, this can be a side-effect of the eager-release attribute when set 'true'. Did you tried to run your test with 'false'? Or is your test successful in standalone OJB? regards, Armin - Original Message - From: Guido Beutler [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 3:27 PM Subject: Re: OJB RC4 does not select all objects? Hi,, I tried a workaround and select all A by a loop with direct primary key access like: select allobject from A where key=$1 Whith this select I get all expected objects but of course this is not very comfortable to code a loop for every IN clause. best regards, Guido Original Message Subject: OJB RC4 does not select all objects? Date: Wed, 01 Oct 2003 14:20:15 +0200 From: Guido Beutler [EMAIL PROTECTED] To: OJB Users List [EMAIL PROTECTED] Hello, I've got a strange problem. I have two Tables A and B with corresponding classes. B has a foreign key to A and so I have a 1:N between A and B. A has a reference-descriptor to B and B has a collection-descriptor to A. If I try to select all instances of A i only get a few entries instead of 20. If I reinvoke the test case the number of retrieved objects raises until 20 is reached. select allobject from A where key is in ($1) $1 is a collection of 20 integers. If I select all objects of B first and then select all A i get the expected 20 objects. In both cases no exception is thrown. I'm using rc4 with ODMG inside of JBoss 3.2.2. with DB/2. Has anybody seen this before? gest regards, Guido - 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]
Re: OJB RC4 does not select all objects?
Hi again, if turning off eager-release=false I get the following Exception: 15:59:17,301 INFO [STDOUT] [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: 15:59:17,302 INFO [STDOUT] executeQuery: [EMAIL PROTECTED] 15:59:17,408 INFO [TxConnectionManager$TxConnectionEventListener] throwable from unregister connection java.lang.IllegalStateException: Trying to return an unknown connection1! [EMAIL PROTECTED] at org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterConnection(CachedConnectionManager.java:264) at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.connectionClosed(TxConnectionManager.java:550) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:287) at org.jboss.resource.adapter.jdbc.WrappedConnection.close(WrappedConnection.java:127) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.resource.connectionmanager.CachedConnectionManager.closeAll(CachedConnectionManager.java:375) at org.jboss.resource.connectionmanager.CachedConnectionManager.popMetaAwareObject(CachedConnectionManager.java:199) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:190) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:72) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:267) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:118) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) at org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:331) at org.jboss.ejb.Container.invoke(Container.java:700) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) What's that?? Seems that OJB creates a connection instead using the data source? best regards, Guido Guido Beutler wrote: Hi Armin, :-) yes I'm using eager-release = 'true' with 'false' my connection pool die's when running under load :-( I'll try 'false' just for a test and post the result. Do you mean that I can not trust select results if running with 'true'? best regards, Guido Armin Waibel wrote: Hi Guido, this can be a side-effect of the eager-release attribute when set 'true'. Did you tried to run your test with 'false'? Or is your test successful in standalone OJB? regards, Armin - Original Message - From: Guido Beutler [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 3:27 PM Subject: Re: OJB RC4 does not select all objects? Hi,, I tried a workaround and select all A by a loop with direct primary key access like: select allobject from A where key=$1 Whith this select I get all expected objects but of course this is not very comfortable to code a loop for every IN clause. best regards, Guido Original Message Subject: OJB RC4 does not select all objects? Date: Wed, 01 Oct 2003 14:20:15 +0200 From: Guido Beutler [EMAIL PROTECTED] To: OJB Users List [EMAIL PROTECTED] Hello, I've got a strange problem. I have two Tables A and B with corresponding classes. B has a foreign key to A and so I have a 1:N between A and B. A has a reference-descriptor to B and B has a collection-descriptor to A. If I try to select all instances of A i only get a few entries instead of 20. If I reinvoke the test case the number of retrieved objects raises until 20 is reached. select allobject from A where key is in ($1) $1 is a collection of 20 integers. If I select all objects of B first and then select all A i get the expected 20 objects. In both cases no exception is thrown. I'm using rc4 with ODMG inside of JBoss 3.2.2. with DB/2. Has anybody seen this before? gest regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: query before commit problem
Hi Armin,
what do you think to make it configurable. For managed enviroment
the default would be a write through (or call it auto flush).
I can not access the cvs so I can not test your new Tx implementation. :-(
best regards,
Guido
Armin Waibel wrote:
Hi Guido,
tx.checkpoint() is not allowed in managed
environments, because it does commit the
'underlying' connection (commit the current tx).
Allowed to use is ((TransactionExt) tx).flush()
(new introduced interface ExtTransaction is not part
of rc4 - use CVS)
this perform object operations on connection without
commit the connection/tx.
regards,
Armin
- Original Message -
From: Guido Beutler [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Sent: Monday, September 15, 2003 1:13 PM
Subject: Re: query before commit problem
Hi,
how to do it in managed enviroment?
transaction.checkpoint()
throws a not supported exception.
best regards,
Guido
Jair da Silva Ferreira Júnior wrote:
Hi,
Thank you Thomas and Charles for your fast answers. I think I'll
use
transaction.checkpoint() as Charles pointed.
By the way, don't you think this would be a nice feature to be
added to
a future OJB version? Say, when an object is persisted insinde a
transaction
it would be nice if any query runned inside that transaction could
see
that object.
Sincerely,
Jair Jr
- Original Message -
From: Charles Anthony [EMAIL PROTECTED]
To: 'OJB Users List' [EMAIL PROTECTED]
Sent: Friday, September 12, 2003 1:52 PM
Subject: RE: query before commit problem
Hi,
As Thomas says, this is by design. However, you can force the
transaction
to
flush all object changes to the database, without committing the
underlying
database connection :
In RC4, you can use Transaction.checkpoint() e.g. t.checkpoint();
After RC4 (i.e. in CVS), you should be able to cast the transaction
to
TransactionExt and invoke TransactionExt.flush
e.g. (TransactionExt) t).flush()
HTH,
Cheers,
Charles.
-Original Message-
From: Thomas Mahler [mailto:[EMAIL PROTECTED]
Sent: 12 September 2003 17:48
To: OJB Users List
Subject: Re: query before commit problem
Hi Jair,
ODMG transaction write to the db only on tx.commit.
Thus q is not persistent in the database when you perform the
first query!
All queries (also ODMG OQL!) are executed against the
database. So it's
obvious that loaded != q after your query.
after commiting the transaction q is stored in the DB and the
second
query does find it.
Works as designed.
-Thomas
Jair da Silva Ferreira Júnior wrote:
Hi,
I am using ojb1.0_rc4, ODMG api with OJB queries and
mysql4. The problem is that when I persist an object and run a
identity query looking for the persisted objet the query
returns null. This only happens when I persist the object and
execute the query in the same transaction. Is this behaviour
correct or is this a bug?
I added some example code in the end of this email for
better understanding.
Thanks for your help.
Sincerely,
Jair Jr
Example code:
void doSomething(){
Transaction t=implementation.newTransaction();
t.begin();
Question q=new Question();
t.lock(q,t.WRITE);
q.setStatement(a statement);
q.setNumber(10);
q.setSubject(Subject.PHYSICS);
q.setCorrectAlternative(Alternative.A);
Question example=new Question();
example.setId(q.getId());
QueryByIdentity query=new QueryByIdentity(example);
Question loaded=(Question)
((HasBroker)t).getBroker().getObjectByQuery(query);
file://loaded==null !!! why? Shouldn't it be: loaded==q?
t.commit();
t=implementation.newTransaction();
t.begin();
query=new QueryByIdentity(example);
loaded=(Question)
((HasBroker)t).getBroker().getObjectByQuery(query);
file://loaded!=null now! loaded==q!
t.commit();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This email and any attachments are strictly confidential and are
intended
solely for the addressee. If you are not the intended recipient you
must
not disclose, forward, copy or take any action in reliance on this
message
or its attachments. If you have received this email in error please
notify
the sender as soon as possible and delete it from your computer
systems.
Any views or opinions presented are solely those of the author and
do not
necessarily reflect those of HPD Software Limited or its affiliates.
At present the integrity of email across the internet cannot be
guaranteed
and messages sent via this medium are potentially at risk. All
liability
is excluded to the extent permitted by law for any claims arising
Re: query before commit problem
Hi Charles, Charles Anthony wrote: Hi, Someone asked for this recently, and I'm afraid I was too busy to reply. No problem :-) When you lock an object (for update), it is *before* you make any changes to it. How can OJB know when to automatically flush changes to the database ? It can't; you have to tell it to. The same applies to locking an object for create; you can lock an object for create, *then* set the values on the object - it is only at commit/flush time that we know what the complete changes are... Yes you're right. But my problem is a little bit different. I've got 2 EJB's let's say A and B. B does all OJB related stuff. A is a statefull session bean. A part of it is I generate session data and store them at the DB. At the end of the session I'm searching for the data and delete them. As long as A is bean managed everything works fine but if A is container managed the commit of the insert of the session data is at the end of the whole session and so the query to delete the data fails and AFTER that the session data are inserted. I tried to set B to trans-attributeRequiresNew/trans-attribute. So the first insert call should get a commit after it's completion and the data should be at the db when querying at the second delete call. This did not change anything. Either JBoss has a problem at the generating of the inner session or OJB is using the outer session any time although there is a inner one. Cheers, Charles best regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: query before commit problem
Hi,
how to do it in managed enviroment?
transaction.checkpoint()
throws a not supported exception.
best regards,
Guido
Jair da Silva Ferreira Júnior wrote:
Hi,
Thank you Thomas and Charles for your fast answers. I think I'll use
transaction.checkpoint() as Charles pointed.
By the way, don't you think this would be a nice feature to be added to
a future OJB version? Say, when an object is persisted insinde a transaction
it would be nice if any query runned inside that transaction could see
that object.
Sincerely,
Jair Jr
- Original Message -
From: Charles Anthony [EMAIL PROTECTED]
To: 'OJB Users List' [EMAIL PROTECTED]
Sent: Friday, September 12, 2003 1:52 PM
Subject: RE: query before commit problem
Hi,
As Thomas says, this is by design. However, you can force the transaction
to
flush all object changes to the database, without committing the
underlying
database connection :
In RC4, you can use Transaction.checkpoint() e.g. t.checkpoint();
After RC4 (i.e. in CVS), you should be able to cast the transaction to
TransactionExt and invoke TransactionExt.flush
e.g. (TransactionExt) t).flush()
HTH,
Cheers,
Charles.
-Original Message-
From: Thomas Mahler [mailto:[EMAIL PROTECTED]
Sent: 12 September 2003 17:48
To: OJB Users List
Subject: Re: query before commit problem
Hi Jair,
ODMG transaction write to the db only on tx.commit.
Thus q is not persistent in the database when you perform the
first query!
All queries (also ODMG OQL!) are executed against the
database. So it's
obvious that loaded != q after your query.
after commiting the transaction q is stored in the DB and the second
query does find it.
Works as designed.
-Thomas
Jair da Silva Ferreira Júnior wrote:
Hi,
I am using ojb1.0_rc4, ODMG api with OJB queries and
mysql4. The problem is that when I persist an object and run a
identity query looking for the persisted objet the query
returns null. This only happens when I persist the object and
execute the query in the same transaction. Is this behaviour
correct or is this a bug?
I added some example code in the end of this email for
better understanding.
Thanks for your help.
Sincerely,
Jair Jr
Example code:
void doSomething(){
Transaction t=implementation.newTransaction();
t.begin();
Question q=new Question();
t.lock(q,t.WRITE);
q.setStatement(a statement);
q.setNumber(10);
q.setSubject(Subject.PHYSICS);
q.setCorrectAlternative(Alternative.A);
Question example=new Question();
example.setId(q.getId());
QueryByIdentity query=new QueryByIdentity(example);
Question loaded=(Question)
((HasBroker)t).getBroker().getObjectByQuery(query);
//loaded==null !!! why? Shouldn't it be: loaded==q?
t.commit();
t=implementation.newTransaction();
t.begin();
query=new QueryByIdentity(example);
loaded=(Question)
((HasBroker)t).getBroker().getObjectByQuery(query);
//loaded!=null now! loaded==q!
t.commit();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This email and any attachments are strictly confidential and are intended
solely for the addressee. If you are not the intended recipient you must
not disclose, forward, copy or take any action in reliance on this message
or its attachments. If you have received this email in error please notify
the sender as soon as possible and delete it from your computer systems.
Any views or opinions presented are solely those of the author and do not
necessarily reflect those of HPD Software Limited or its affiliates.
At present the integrity of email across the internet cannot be
guaranteed
and messages sent via this medium are potentially at risk. All liability
is excluded to the extent permitted by law for any claims arising as a re-
sult of the use of this medium to transmit information by or to
HPD Software Limited or its affiliates.
-
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]
Deadlocks during OJB internal table access
Hello, I'm using OJB 1.0 rc4 inside of jboss3.2.2rc3 and db2. OJB is running into self generated deadlocks if I access ojb with concurrent ejb clients when using SequenceManagerNextValImpl As a workaround I use SequenceManagerInMemoryImpl but I think this won't work with sequences. If ojb could access his internal tables with read uncommitted this should not occur but it seems that OJB does not commit it's entries at the internal tables, especially the sequence id's. What can I do to get rid of the deadlocks? best regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deadlocks during OJB internal table access
Hi Armin, Armin Waibel wrote: Hi Guido, Hello, I'm using OJB 1.0 rc4 inside of jboss3.2.2rc3 and db2. OJB is running into self generated deadlocks if I access ojb with concurrent ejb clients when using SequenceManagerNextValImpl As a workaround I use SequenceManagerInMemoryImpl but I think this won't work with sequences. If ojb could access his internal tables with read uncommitted this should not occur but it seems that OJB does not commit it's entries at the internal tables, especially the sequence id's. Running within a j2ee container OJB should not commit any tx/connections. Each from OJB obtained DataSource was automatically enlisted in the running tx (thus it's not allowed to commit). Further I think it's not allowed to change transactionIsolation of DataSources (but maybe I'm wrong). I think it won't be a good idea to change the isolation state of the data source (even if it may be possible). What can I do to get rid of the deadlocks? Good question ;-) Can you discribe the deadlock more detailed? When does it occur, when create new sequence name (OJB can create missing sequence names by itself) or when lookup next sequence key? Yes, at the lookup of the next sequence key at the same transaction. If I have to generate only one new sequence id per transaction everything works fine. I already thought about a RequiresNew attribute (see my other mail OJB getting wrong transactin context or RequiresNew attribute (JBoss) seems not to start new transaction at the list) and wrap all ojb stuff to own new transactions. The idea was to get commits earlier than at the end of the one large transaction. This would avoid to generate several id's at one transaction but this didn't work with jboss :-( . Can you write a test case (not ejb based) to reproduce your problem? I think that the problem has to do with the transaction layer inside of the ejb context so I don't think that it is reproduceable outside of the ejb server. I wasn't clear about the fact that the commits of the internal ojb tables are dependent on the EJB transaction. There is a multithreaded test case in CVS called 'SMMultithreadedTest'. This test simulate concurrent clients. This test pass when I use SequenceManagerNextValImpl and sapDB. But it is not a ejb test case isn't it? Anyway I should check it. best regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB uses jdbc cursor to Update - but my cursor doesn't suppor t up date!
Hello Alex,
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'm
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: yy 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
t
up date!
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
t
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 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?
Yes, that would be another option. But it would mean to keep the ODMG
tx
open during the client operations. And when the client returns the
changes object you have to looup the proper transaction.
cheers,
Thomas
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);
}
/**
Update problem at ODMG Interface inside jboss
Hi, I've got a problem during update of objects inside of jboss. I'm using ojb rc4 and jboss-3.2.2RC3. My code looks like: Transaction tx= _impl.currentTransaction(); tx.lock(obj, Transaction.WRITE); First time the object is inserted. Then I change a attribute of the object and execute the write method again., but the values at the database are not changed. How do I have to performe updates? Thankx, best regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NEWBIE: cannot update object with ODMG
Hi,
- Original Message -
From: Farnea Massimiliano [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, March 06, 2003 12:58 PM
Subject: NEWBIE: cannot update object with ODMG
I'm testing the ODMG layer with this example:
/**
* Update the Traente instance on the database
*/
public void update() {
Database db = odmg.newDatabase(); // the current DB
Transaction tx = null;
//open database
try {
db.open(default, Database.OPEN_READ_WRITE);
} catch (ODMGException ex) {
ex.printStackTrace();
}
tx = odmg.newTransaction();
String oqlQuery = select edit from +
traente.className +
where id = + traente.getId();
try {
tx = odmg.newTransaction();
you got 2 transactions now. I think you need only one.
tx.begin();
OQLQuery query = odmg.newOQLQuery();
query.create(oqlQuery);
DList result = (DList) query.execute();
Traente toBeEdited = (Traente) result.get(0);
tx.lock(toBeEdited, Transaction.UPGRADE);
At the tutorial page the OJB crew uses
tx.lock(toBeEdited, Transaction.WRITE);
for updating values.
toBeEdited = traente;
what's traente at that point?
tx.commit();
second transaction is commited but the first one is still in use.
cheers,
Guido
} catch (Throwable t) {
// rollback in case of errors
tx.abort();
t.printStackTrace();
}finally {
try {
db.close();
System.out.println(DB closed);
} catch (ODMGException ex) {
ex.printStackTrace();
}
}
}
where 'traente' is a class attribute that rapresents the updated object
that
i would like to persist.
After the method invocation the database still contains the old
object,
while retrieving again the reference 'toBeEdited' it seems to be updated.
What do I miss? I'm using a test class on JBuilder, without any particular
deployement enviroment.
Thanks in advance
Massimiliano Farnea
-
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]
Re: OJB 0.99 writing to the database in jboss! Please help
Hi, I ran into the same problem. Is there a solution avail? cheers, Guido - Original Message - From: Ashraf Moosa [EMAIL PROTECTED] To: OJB Users List [EMAIL PROTECTED] Sent: Tuesday, February 18, 2003 10:09 AM Subject: OJB 0.99 writing to the database in jboss! Please help Hi, I am having the same problems as Cristos. I am upgrading from version 0.9.8. I can successfully read from the database but when I try to add or update everything executes cleanly but nothing commits to the database. I have tried in with implicit locking set to true as well as false. Ashraf On Fri, 2003-02-14 at 13:02, Cristos Dimitriou wrote: Hi all, I have recently upgrade to Version 0.9.9. Currently the environment that i am running is a managed environment(JBOSS) connecting to a postgres db. I am having problems writing to the database, more specifically, the application executes cleanly with no runtime errors however no values have been writen to the db. It seems that i have only aquired a read lock to the database but the code that I am using in order to obtain a database is as follows: db.open(default#user#pwd,Database.OPEN_READ_WRITE); Does anyone have any ideas? Thanks in advance Cristos Dimitriou - 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]
EJBException with OJB 0.9.7
Hi, I'm searching a strange error with the JBoss 3.0.4 TX layer and OJB. The applcation is working for a while and 'suddenly' JBoss throws a EJBException (see below). I'm not realy sure that this has to do with OJB, so I would like to know if anybody has seen this before. thanks, cheers, Guido 16:06:36,916 ERROR [LogInterceptor] EJBException: javax.ejb.EJBException: Application Error: tried to enter Stateful bean with different transaction context, contextTx: TransactionImpl:XidImpl [FormatId=257, GlobalId=yoda//254, BranchQual=], methodTx: TransactionImpl:XidImpl [FormatId=257, GlobalId=yoda//255, BranchQual=] at org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSess ionInstanceInterceptor.java:228) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor .java:107) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT. java:178) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:60) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204) at org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java: 380) at org.jboss.ejb.Container.invoke(Container.java:712) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:382) at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:7 01) at java.lang.Thread.run(Thread.java:536) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Locking exception with OJB 0.9.8 and JBoss
Hi, during storing an object I get following exception. I use OJB 0.9.8 and DB2 V7.2 with app driver. Any Idea whats going on? cheers, Guido 13:38:35,082 INFO [STDOUT] [org.apache.ojb.odmg.OJBJ2EE_2] INFO: 13:38:35,083 INFO [STDOUT] beginInternTransaction was called 13:38:35,150 INFO [STDOUT] [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG: 13:38:35,152 INFO [STDOUT] SQL: SELECT A0.TIMESTAMP_,A0.ISOLATIONLEVEL,A0.TX_ID,A0.LOCKTYPE,A0.OID_ FROM OJB_LOCKENTRY A0 WHERE A0.TIMESTAMP_ ? 13:38:35,175 INFO [STDOUT] [org.apache.ojb.broker.accesslayer.JdbcAccess] ERROR: 13:38:35,177 INFO [STDOUT] SQLException during the execution of the query (for a org.apache.ojb.odmg.locking.LockEntry): [IBM][CLI Driver] CLI0102E Invalid conversion. SQLSTATE=07006 13:38:35,178 INFO [STDOUT] [IBM][CLI Driver] CLI0102E Invalid conversion. SQLSTATE=07006 13:38:35,179 ERROR [STDERR] COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] CLI0102E Invalid conversion. SQLSTATE=07006 13:38:35,184 ERROR [STDERR] at COM.ibm.db2.jdbc.app.SQLExceptionGenerator.throw_SQLException(SQLExceptionGe nerator.java:269) 13:38:35,185 ERROR [STDERR] at COM.ibm.db2.jdbc.app.SQLExceptionGenerator.throw_SQLException(SQLExceptionGe nerator.java:206) 13:38:35,187 ERROR [STDERR] at COM.ibm.db2.jdbc.app.SQLExceptionGenerator.check_return_code(SQLExceptionGen erator.java:457) 13:38:35,188 ERROR [STDERR] at COM.ibm.db2.jdbc.app.DB2PreparedStatement.execute2(DB2PreparedStatement.java :1759) 13:38:35,190 ERROR [STDERR] at COM.ibm.db2.jdbc.app.DB2PreparedStatement.executeQuery(DB2PreparedStatement. java:1247) 13:38:35,191 ERROR [STDERR] at org.jboss.resource.adapter.jdbc.local.LocalPreparedStatement.executeQuery(Lo calPreparedStatement.java:289) 13:38:35,192 ERROR [STDERR] at org.apache.ojb.broker.accesslayer.JdbcAccess.executeQuery(Unknown Source) 13:38:35,194 ERROR [STDERR] at org.apache.ojb.broker.accesslayer.RsIterator.init(Unknown Source) 13:38:35,195 ERROR [STDERR] at org.apache.ojb.broker.singlevm.RsIteratorFactoryImpl.createRsIterator(Unknow n Source) 13:38:35,197 ERROR [STDERR] at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getRsIteratorFromQuery( Unknown Source) 13:38:35,198 ERROR [STDERR] at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getRsIteratorFromQueryE xtentAware(Unknown Source) 13:38:35,199 ERROR [STDERR] at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getIteratorFromQuery(Un known Source) 13:38:35,201 ERROR [STDERR] at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getIteratorByQuery(Unkn own Source) 13:38:35,202 ERROR [STDERR] at org.apache.ojb.broker.singlevm.DelegatingPersistenceBroker.getIteratorByQuer y(Unknown Source) 13:38:35,204 ERROR [STDERR] at org.apache.ojb.odmg.locking.PersistentLockMapImpl.removeTimedOutLocks(Unknow n Source) 13:38:35,205 ERROR [STDERR] at org.apache.ojb.odmg.locking.PersistentLockMapImpl.getWriter(Unknown Source) 13:38:35,206 ERROR [STDERR] at org.apache.ojb.odmg.locking.AbstractLockStrategy.getWriter(Unknown Source) 13:38:35,207 ERROR [STDERR] at org.apache.ojb.odmg.locking.ReadUncommittedStrategy.writeLock(Unknown Source) 13:38:35,209 ERROR [STDERR] at org.apache.ojb.odmg.locking.LockManagerDefaultImpl.writeLock(Unknown Source) 13:38:35,210 ERROR [STDERR] at org.apache.ojb.odmg.TransactionImpl.lock(Unknown Source) 13:38:35,211 ERROR [STDERR] at org.apache.ojb.odmg.NarrowTransaction.lock(Unknown Source) 13:38:35,212 ERROR [STDERR] at de.hrs.hsv.HSVSessionManagerEJB.addSession(Unknown Source) 13:38:35,214 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 13:38:35,215 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) 13:38:35,216 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) 13:38:35,218 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:324) 13:38:35,219 ERROR [STDERR] at org.jboss.ejb.EntityContainer$ContainerInterceptor.invoke(EntityContainer.ja va:1197) 13:38:35,220 ERROR [STDERR] at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchron izationInterceptor.java:340) 13:38:35,222 ERROR [STDERR] at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(Cach edConnectionInterceptor.java:186) 13:38:35,223 ERROR [STDERR] at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterce ptor.java:193) 13:38:35,225 ERROR [STDERR] at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.jav a:107) 13:38:35,226 ERROR [STDERR] at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterce ptor.java:69) 13:38:35,227 ERROR [STDERR] at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor .java:96) 13:38:35,229 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT. java:167) 13:38:35,230 ERROR [STDERR] at
OJB Database creation inside J2EE (JBoss)
Hello, I'm accessing OJB inside JBoss 3.0.x. Inside of a session EJB I want to get a Database reference. Calling: Database _ojbDb = null; String pmname = java:/ojb/defaultODMG; ... InitialContext jndiContext = new InitialContext(); ODMGJ2EEFactory factory = (ODMGJ2EEFactory) jndiContext.lookup(pmname); Implementation _ojbImpl = factory.getInstance(); _ojbDb.open(repository.xml, Database.OPEN_READ_WRITE); works fine. But what happens ? For me it looks like I am opening a database but OJB uses a DataService inside so the Database (JDBC Connect) should be open already. I wasn't able t find a sample, so maybe that everything is all right, I'm just not sure about that. If it is all right, why do I have to give the name of the repository.xml every time? thanks, cheers, Guido Beutler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
