You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Miroslav Lazarević <mi...@ptt.yu> on 2003/06/03 13:30:05 UTC
ODMG and collection descriptor
Hi,
I have a question about collection descriptor's auto-retrieve, auto-update and
auto-delete attributes when using ODMG API. In documentation is written that
for OTM, ODMG and JDO auto-retrieve="true", auto-update="false" and
auto-delete="false". I have a two classes which everyone contain collections
of eachother. When I store object using ODMG API I get only that object
inserted in database without inserted collection's data in third table which
serve to contain M:N mappings data. If I manually add row in that table when
loading object then I get collection filled from that help table as expected.
I suppose that it's happend because auto-retrieve is true for ODMG. Should I
must do any extra work to make this collection updateable when using ODMG?
--
Best regards,
Mickey mikey@ptt.yu, mikeai@sezampro.yu
why does it return null?
Posted by Leon <le...@hotmail.com>.
Hi,
I saw some post about this question and solutions on the mail list and
follow the suggestions and put code into my class. but it seems not working.
This is the code.
broker = ServiceLocator.getInstance().findBroker();
Criteria criteria =new Criteria();
criteria.addEqualTo("email", primaryKey.trim());
Query query = new QueryByCriteria(RegistryVOBean.class, criteria, true);
InitialContext ctx = new InitialContext();
tx.begin();
RegistryVOBean retrieved = (RegistryVOBean)broker.getObjectByQuery(query);
if (retrieved == null){
UserNotExistingException ex = new UserNotExistingException(primaryKey + "is
not existing!");
throw new DataAccessException(primaryKey + "is not existing.", ex);
}
logonVo = new LogonVOBean();
logonVo.setEmailAddress(retrieved.getEmail());
logonVo.setPassword(retrieved.getPassword());
tx.commit();
I got the following loggin and exceptions.
[org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl] INFO:
Create PersistenceBroker instance pool, pool configuration was
{whenExhaustedAction=0, maxIdle=-1, maxActive=100, maxWait=2000,
removeAbandoned=false, numTestsPerEvictionRun=10, testWhileIdle=false,
minEvictableIdleTimeMillis=1000000, testOnReturn=false, logAbandoned=false,
removeAbandonedTimeout=300, timeBetweenEvictionRunsMillis=-1,
testOnBorrow=false}
[org.apache.ojb.broker.metadata.RepositoryPersistor] INFO: OJB Descriptor
Repository:
zip:D:/bea/user_projects/mydomain/myserver/stage/_appsdir_WebContent_war/Web
Content.war!/WEB-INF/classes/repository.xml
[org.apache.ojb.broker.metadata.RepositoryPersistor] INFO: Read class
descriptors took 234 ms
[org.apache.ojb.broker.metadata.RepositoryPersistor] INFO: OJB Descriptor
Repository:
zip:D:/bea/user_projects/mydomain/myserver/stage/_appsdir_WebContent_war/Web
Content.war!/WEB-INF/classes/repository.xml
[org.apache.ojb.broker.metadata.RepositoryPersistor] INFO: Read connection
repository took 109 ms
[org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl] INFO: Set
default PBKey: org.apache.ojb.broker.PBKey: jcdAlias=xegledbconn,
user=system, password=*****
[org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl] DEBUG:
createPersistenceBroker(key) called
[org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl] INFO:
Create new PB instance for PBKey org.apache.ojb.broker.PBKey:
jcdAlias=xegledbconn, user=system, password=*****, already created
persistence broker instances: 0
[org.apache.ojb.broker.core.PersistenceBrokerImpl] DEBUG:
getCollectionByQuery (class
org.apache.ojb.broker.util.collections.RemovalAwareCollection, class
com.xegle.systems.registry.RegistryVOBean, Query from class
com.xegle.systems.registry.RegistryVOBean where
org.apache.ojb.broker.query.Criteria@1eafe13)
[org.apache.ojb.broker.core.PersistenceBrokerImpl] DEBUG: Creating
RsIterator for class [com.xegle.systems.registry.RegistryVOBean]
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:SELECT DISTINCT
A0.locale,A0.password,A0.submission_date,A0.answer,A0.email,A0.birth_day,A0.
last_name,A0.account_id,A0.question,A0.first_name FROM T_ACCOUNT A0 WHERE
A0.email = ?
An exception has been caused by:
java.lang.NullPointerException
at
com.xegle.systems.logon.LogonManagerBD.authenticateUser(LogonManagerBD.java:
36)
at
com.xegle.systems.logon.LogonManagerBD.validateSignOn(LogonManagerBD.java:27
)
at com.xegle.systems.logon.struts.LogonAction.logon(LogonAction.java:38)
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.apache.struts.actions.DispatchAction.dispatchMethod(DispatchAction.java:
280)
at
org.apache.struts.actions.DispatchAction.execute(DispatchAction.java:216)
at
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProces
sor.java:480)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1420)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:520)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(Servle
tStubImpl.java:1058)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java
:401)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java
:306)
at
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(W
ebAppServletContext.java:5445)
at
weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManage
r.java:780)
at
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletCo
ntext.java:3105)
at
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java
:2588)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189)
[org.apache.ojb.broker.core.PersistenceBrokerImpl] DEBUG: PB.close was
called: org.apache.ojb.broker.core.PersistenceBrokerImpl@c47680
[org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl] ERROR:
Closing connection failed
Could not release connection to pool:
java.lang.NullPointerException
java.sql.SQLException: Could not release connection to pool:
java.lang.NullPointerException
at weblogic.jdbc.pool.Connection.close(Connection.java:213)
at weblogic.jdbc.rmi.internal.ConnectionImpl.close(ConnectionImpl.java:198)
at weblogic.jdbc.rmi.SerialConnection.close(SerialConnection.java:211)
at
org.apache.ojb.broker.util.WrappedConnection.close(WrappedConnection.java:16
7)
at
org.apache.ojb.broker.util.pooling.ByPassConnection.close(ByPassConnection.j
ava:55)
at
org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.releaseConne
ction(ConnectionFactoryAbstractImpl.java:64)
at
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.releaseConnection(Co
nnectionManagerImpl.java:302)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.close(PersistenceBrokerImpl
.java:320)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.finalize(PersistenceBrokerI
mpl.java:2402)
at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
Could you help me out?
Cheers
Leon
Re: ODMG and collection descriptor
Posted by Miroslav Lazarević <mi...@ptt.yu>.
Hi Thomas,
first, thanks for your response.
On Tuesday 03 June 2003 18:42, Thomas Mahler wrote:
>
> Yes, you have to lock the elements of the N side collection to the open
> ODMG transaction!
> Otherwise OJB/ODMG won't detect the changes to those objects and thus
> won't perform any updates for them.
>
> If you are using the ODMG persistent collections like DList you don't
> have to do the locking, as they cooperate with the transaction mechanism.
>
> DLists are also very handy for m:n associations, as you don't need an
> intermediary table, OJB is doing all the management stuff for you...
>
Could you tell me does exist example of your story somewhere in CVS?
--
Best regards,
Mickey mikey@ptt.yu, mikeai@sezampro.yu
Re: ODMG and collection descriptor
Posted by Miroslav Lazarević <mi...@ptt.yu>.
On Tuesday 03 June 2003 18:42, Thomas Mahler wrote:
>
> Yes, you have to lock the elements of the N side collection to the open
> ODMG transaction!
> Otherwise OJB/ODMG won't detect the changes to those objects and thus
> won't perform any updates for them.
>
> If you are using the ODMG persistent collections like DList you don't
> have to do the locking, as they cooperate with the transaction mechanism.
>
> DLists are also very handy for m:n associations, as you don't need an
> intermediary table, OJB is doing all the management stuff for you...
>
Hi Thomas,
I tried to implement this, but I hadn't success. Could you give me a some
example of using DList for collections? How must repository look like for in
this case? Does object which I store must have a collection of DList type?
Please, help me about this.
--
Best regards,
Mickey mikey@ptt.yu, mikeai@sezampro.yu
Re: refreshing a connection
Posted by Armin Waibel <ar...@code-au-lait.de>.
Hi,
use 'validationQuery' in your jdbc-connection-descriptor.
Then OJB do a 'real' query before a connection was returned.
This is a minor performance impact, but this should solve your
problem.
regards,
Armin
----- Original Message -----
From: "luke cassady-dorion" <lu...@netraker.com>
To: "'OJB Users List'" <oj...@db.apache.org>
Sent: Wednesday, June 04, 2003 7:32 PM
Subject: refreshing a connection
> A requirement for my application is that the application can continue
to
> service requests even if the database connection is severed. In order
to
> do this, i'm putting insert requests into a queue and pushing them
back
> on if they fail. What i'm finding tho is that the if the db is started
> and stopped that the ojb connection pool does not refresh itself nor
can
> i force the pool to replace the connection with a new one. Am i
missing
> something?
>
> I'm using mssql server if that matters.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
refreshing a connection
Posted by luke cassady-dorion <lu...@netraker.com>.
A requirement for my application is that the application can continue to
service requests even if the database connection is severed. In order to
do this, i'm putting insert requests into a queue and pushing them back
on if they fail. What i'm finding tho is that the if the db is started
and stopped that the ojb connection pool does not refresh itself nor can
i force the pool to replace the connection with a new one. Am i missing
something?
I'm using mssql server if that matters.
Re: ODMG and collection descriptor
Posted by Thomas Mahler <th...@web.de>.
Hi Miroslav,
Miroslav Lazarevic' wrote:
> Hi,
>
> I have a question about collection descriptor's auto-retrieve, auto-update and
> auto-delete attributes when using ODMG API. In documentation is written that
> for OTM, ODMG and JDO auto-retrieve="true", auto-update="false" and
> auto-delete="false".
that's still correct!
> I have a two classes which everyone contain collections
> of eachother. When I store object using ODMG API I get only that object
> inserted in database without inserted collection's data in third table which
> serve to contain M:N mappings data. If I manually add row in that table when
> loading object then I get collection filled from that help table as expected.
> I suppose that it's happend because auto-retrieve is true for ODMG. Should I
> must do any extra work to make this collection updateable when using ODMG?
Yes, you have to lock the elements of the N side collection to the open
ODMG transaction!
Otherwise OJB/ODMG won't detect the changes to those objects and thus
won't perform any updates for them.
If you are using the ODMG persistent collections like DList you don't
have to do the locking, as they cooperate with the transaction mechanism.
DLists are also very handy for m:n associations, as you don't need an
intermediary table, OJB is doing all the management stuff for you...
cheers,
Thomas
>