Re: JDO - Objects fetched from DB are in transient state, not persistent
Hi Ketan,
Ketan Gangatirkar wrote:
Thomas,
I tried using the method in tutorial4 to look up objects by OID, but I
kept getting javax.jdo.JDOUserException: Given object is not a valid
OID. This is the relevant code section, basically copied out of
org.apache.ojb.tutorial5.UCEditProduct and adapted slightly:
PersistenceManagerFactory pmf = new OjbStorePMF();
PersistenceManager pm = pmf.getPersistenceManager();
Building example = new Building();
example.setBuildingID(4);
Identity oid = new Identity(example);
pm.currentTransaction().begin();
Building building = (Building) pm.getObjectById(oid, false);
Mhh, that's quite strange! that's the virtually the same code as in my
UCEdit Example.
I definitely works with the Product class. Do you get the OJB JDO
tutorial app running with the UCEdit usecase on your machine?
AFter looking clsoer at the JDORI I have an idea:
The problem could be caused because in my UCEdit the object to lookup is
already in the JDORI cache. In your it is not and the cache wants to
create a new SM, which then fails.
you could try to load the complete extent of your Building objects and
iterate through it before calling your code fragment.
If it works, my assumption is correct, and I have even more work to do :-(
cheers,
Thomas
oid.toString() returns org.lbjnow.calvin.location.Building{4} which
certainly looks plausible.
As a result, the work-around does not work :-/. This happens with all
my objects; I just picked the simplest to demonstrate. The
repository_user.xml section is:
class-descriptor class=org.lbjnow.calvin.location.Building
table=building
field-descriptor id=1 name=buildingID column=building_id
jdbc-type=INTEGER primarykey=true autoincrement=true
sequence-name=building_id_seq /
field-descriptor id=2 name=shortName column=short_name
jdbc-type=VARCHAR/
field-descriptor id=3 name=longName column=long_name
jdbc-type=VARCHAR/
/class-descriptor
The part of the .jdo file for that class is:
class name=Building identity-type=application
objectid-class=java.lang.Integer
field name=buildingID primary-key=true
null-value=exception /
field name=shortName /
field name=longName /
/class
The class itself is rather simple right now, with just the fields listed
above and the appropriate getter/setter methods. The rest of the
exception looks like this:
javax.jdo.JDOUserException: Given object is not a valid OID.
FailedObject:org.lbjnow.calvin.location.Building{4}
NestedThrowables:
java.lang.IllegalArgumentException: arg1
at com.sun.jdori.common.CacheManagerImpl.createNewSM(Unknown Source)
at com.sun.jdori.common.CacheManagerImpl.getStateManager(Unknown
Source)
at com.sun.jdori.common.CacheManagerImpl.getObjectById(Unknown Source)
at com.sun.jdori.common.PersistenceManagerImpl.getObjectById(Unknown
Source)
at
com.sun.jdori.common.PersistenceManagerWrapper.getObjectById(Unknown
Source)
at org.apache.jsp.tj_jsp._jspService(tj_jsp.java:83)
If I can get lookups to work this way, that would certainly suffice for
my needs.
Thomas Mahler wrote:
Hi again ketan,
Ketan Gangatirkar wrote:
The only problem seems to be that I did not manage to transfer the
correct
state information during the retrieval of extents. Only if you rely
on this
state information you'll get problems...
Ah, there it is. I have this problem when retrieving objects from
JDOQL queries as well as using the methods defined by Extent. Did I
misunderstand you?
No, that's what I meant. JDOQL queries rely on extents, that's why.
The tutorial app does only edit objects based on a primary key lookup...
-
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: JDO - Objects fetched from DB are in transient state, not persistent
Thomas,
I tried using the method in tutorial4 to look up objects by OID, but I
kept getting javax.jdo.JDOUserException: Given object is not a valid
OID. This is the relevant code section, basically copied out of
org.apache.ojb.tutorial5.UCEditProduct and adapted slightly:
PersistenceManagerFactory pmf = new OjbStorePMF();
PersistenceManager pm = pmf.getPersistenceManager();
Building example = new Building();
example.setBuildingID(4);
Identity oid = new Identity(example);
pm.currentTransaction().begin();
Building building = (Building) pm.getObjectById(oid, false);
oid.toString() returns org.lbjnow.calvin.location.Building{4} which
certainly looks plausible.
As a result, the work-around does not work :-/. This happens with all
my objects; I just picked the simplest to demonstrate. The
repository_user.xml section is:
class-descriptor class=org.lbjnow.calvin.location.Building
table=building
field-descriptor id=1 name=buildingID column=building_id
jdbc-type=INTEGER primarykey=true autoincrement=true
sequence-name=building_id_seq /
field-descriptor id=2 name=shortName column=short_name
jdbc-type=VARCHAR/
field-descriptor id=3 name=longName column=long_name
jdbc-type=VARCHAR/
/class-descriptor
The part of the .jdo file for that class is:
class name=Building identity-type=application
objectid-class=java.lang.Integer
field name=buildingID primary-key=true
null-value=exception /
field name=shortName /
field name=longName /
/class
The class itself is rather simple right now, with just the fields listed
above and the appropriate getter/setter methods. The rest of the
exception looks like this:
javax.jdo.JDOUserException: Given object is not a valid OID.
FailedObject:org.lbjnow.calvin.location.Building{4}
NestedThrowables:
java.lang.IllegalArgumentException: arg1
at com.sun.jdori.common.CacheManagerImpl.createNewSM(Unknown Source)
at com.sun.jdori.common.CacheManagerImpl.getStateManager(Unknown Source)
at com.sun.jdori.common.CacheManagerImpl.getObjectById(Unknown Source)
at com.sun.jdori.common.PersistenceManagerImpl.getObjectById(Unknown
Source)
at com.sun.jdori.common.PersistenceManagerWrapper.getObjectById(Unknown
Source)
at org.apache.jsp.tj_jsp._jspService(tj_jsp.java:83)
If I can get lookups to work this way, that would certainly suffice for
my needs.
Thomas Mahler wrote:
Hi again ketan,
Ketan Gangatirkar wrote:
The only problem seems to be that I did not manage to transfer the
correct
state information during the retrieval of extents. Only if you rely
on this
state information you'll get problems...
Ah, there it is. I have this problem when retrieving objects from
JDOQL queries as well as using the methods defined by Extent. Did I
misunderstand you?
No, that's what I meant. JDOQL queries rely on extents, that's why.
The tutorial app does only edit objects based on a primary key lookup...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDO - Objects fetched from DB are in transient state, not persistent
Thomas, I was wondering if you'd been able to determine the right way to proceed with this. If I understood correctly before, the JDO layer is broken and has been for some time. But that can't be right, since other people are using JDO. Regardless, I hope you find the solution; it's kind of hard to use JDO when it's read-only :-). Thanks. Thomas Mahler wrote: Hi Ketan, Ketan Gangatirkar wrote: Thomas, I've been stepping through the OBJ JDO and JDORI code. I have determined that the PersistenceCapable objects never are assigned a StateManager (member jdoStateManager) when they are assembled from a row result. That's exactly the problem! I'm currently researching how to solve this issue. When an object is created and persisted, it does get assigned a StateManager, but I see no corresponding assignment for objects fetched from the DB. I does does happen when objects are retrieved by Identity in OjbStoreManager.fetch. But it does not happen when loading object via a query or a whole Extent. I'm currently trying to implement the StateManager assignment in OjbExtent too. But it's not as easy as I hoped... I'll need a closer look at the JDORI again... cheers, Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDO - Objects fetched from DB are in transient state, not persistent
Hi again ketan, Ketan Gangatirkar wrote: The only problem seems to be that I did not manage to transfer the correct state information during the retrieval of extents. Only if you rely on this state information you'll get problems... Ah, there it is. I have this problem when retrieving objects from JDOQL queries as well as using the methods defined by Extent. Did I misunderstand you? No, that's what I meant. JDOQL queries rely on extents, that's why. The tutorial app does only edit objects based on a primary key lookup... cheers, Thomas - 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: JDO - Objects fetched from DB are in transient state, not persistent
Hi Ketan, Thomas, I was wondering if you'd been able to determine the right way to proceed with this. I hope to fix the problem within the next 3 weeks. If I understood correctly before, the JDO layer is broken and has been for some time. But that can't be right, since other people are using JDO. It's not really broker. you can use it and insert and update objects. The JDO tutorial application is running without problems! The only problem seems to be that I did not manage to transfer the correct state information during the retrieval of extents. Only if you rely on this state information you'll get problems... Regardless, I hope you find the solution; it's kind of hard to use JDO when it's read-only :-). Thanks. it stays on my todo list untils it's fixed! cheers, Thomas Thomas Mahler wrote: Hi Ketan, Ketan Gangatirkar wrote: Thomas, I've been stepping through the OBJ JDO and JDORI code. I have determined that the PersistenceCapable objects never are assigned a StateManager (member jdoStateManager) when they are assembled from a row result. That's exactly the problem! I'm currently researching how to solve this issue. When an object is created and persisted, it does get assigned a StateManager, but I see no corresponding assignment for objects fetched from the DB. I does does happen when objects are retrieved by Identity in OjbStoreManager.fetch. But it does not happen when loading object via a query or a whole Extent. I'm currently trying to implement the StateManager assignment in OjbExtent too. But it's not as easy as I hoped... I'll need a closer look at the JDORI again... cheers, Thomas - 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: JDO - Objects fetched from DB are in transient state, not persistent
Thomas,
I tried your suggestion. I don't know how to interpret the results,
though :-). I changed the code fragment to:
PersistenceManagerFactory pmf = new OjbStorePMF();
PersistenceManager pm = pmf.getPersistenceManager();
PersistenceBrokerFactory.defaultPersistenceBroker().clearCache();
pm.currentTransaction().begin();
Extent extent = pm.getExtent(Building.class, false);
for (Iterator iterator = extent.iterator();
iterator.hasNext();)
{
Building b = (Building) iterator.next();
}
pm.currentTransaction().commit();
Building example = new Building();
example.setBuildingID(4);
Identity oid = new Identity(example);
pm.currentTransaction().begin();
Building building = (Building) pm.getObjectById(oid, false);
However, I am still getting the same exception:
javax.jdo.JDOUserException: Given object is not a valid OID.
FailedObject:org.lbjnow.calvin.location.Building{4}
NestedThrowables:
java.lang.IllegalArgumentException: arg1
at com.sun.jdori.common.CacheManagerImpl.createNewSM(Unknown Source)
at com.sun.jdori.common.CacheManagerImpl.getStateManager(Unknown Source)
at com.sun.jdori.common.CacheManagerImpl.getObjectById(Unknown Source)
at com.sun.jdori.common.PersistenceManagerImpl.getObjectById(Unknown
Source)
at com.sun.jdori.common.PersistenceManagerWrapper.getObjectById(Unknown
Source)
at org.apache.jsp.tj_jsp._jspService(tj_jsp.java:143)
I haven't had any problems using getObjectById() on objects that have
just been persisted (consistent with the root problem), if I remember
correctly. Also, as before, when I iterate through the Extent, the
objects all return false to jdoIsPersistent(). I also tried
pm.getObjectById(new Identity(b)) from within the Extent iteration loop,
which threw the same JDOUserException.
I can't tell if this is good news or bad; hopefully this gives you
enough information to tell. If nothing else, it's consistent!
Thomas Mahler wrote:
Hi Ketan,
Ketan Gangatirkar wrote:
Thomas,
I tried using the method in tutorial4 to look up objects by OID, but I
kept getting javax.jdo.JDOUserException: Given object is not a valid
OID. This is the relevant code section, basically copied out of
org.apache.ojb.tutorial5.UCEditProduct and adapted slightly:
PersistenceManagerFactory pmf = new OjbStorePMF();
PersistenceManager pm = pmf.getPersistenceManager();
Building example = new Building();
example.setBuildingID(4);
Identity oid = new Identity(example);
pm.currentTransaction().begin();
Building building = (Building) pm.getObjectById(oid, false);
Mhh, that's quite strange! that's the virtually the same code as in my
UCEdit Example.
I definitely works with the Product class. Do you get the OJB JDO
tutorial app running with the UCEdit usecase on your machine?
AFter looking clsoer at the JDORI I have an idea:
The problem could be caused because in my UCEdit the object to lookup is
already in the JDORI cache. In your it is not and the cache wants to
create a new SM, which then fails.
you could try to load the complete extent of your Building objects and
iterate through it before calling your code fragment.
If it works, my assumption is correct, and I have even more work to do :-(
cheers,
Thomas
oid.toString() returns org.lbjnow.calvin.location.Building{4} which
certainly looks plausible.
As a result, the work-around does not work :-/. This happens with all
my objects; I just picked the simplest to demonstrate. The
repository_user.xml section is:
class-descriptor class=org.lbjnow.calvin.location.Building
table=building
field-descriptor id=1 name=buildingID column=building_id
jdbc-type=INTEGER primarykey=true autoincrement=true
sequence-name=building_id_seq /
field-descriptor id=2 name=shortName column=short_name
jdbc-type=VARCHAR/
field-descriptor id=3 name=longName column=long_name
jdbc-type=VARCHAR/
/class-descriptor
The part of the .jdo file for that class is:
class name=Building identity-type=application
objectid-class=java.lang.Integer
field name=buildingID primary-key=true
null-value=exception /
field name=shortName /
field name=longName /
/class
The class itself is rather simple right now, with just the fields
listed above and the appropriate getter/setter methods. The rest of
the exception looks like this:
javax.jdo.JDOUserException: Given object is not a valid OID.
FailedObject:org.lbjnow.calvin.location.Building{4}
NestedThrowables:
java.lang.IllegalArgumentException: arg1
at com.sun.jdori.common.CacheManagerImpl.createNewSM(Unknown Source)
at com.sun.jdori.common.CacheManagerImpl.getStateManager(Unknown
Source)
at com.sun.jdori.common.CacheManagerImpl.getObjectById(Unknown
Source)
at
com.sun.jdori.common.PersistenceManagerImpl.getObjectById(Unknown Source)
at
Re: JDO - Objects fetched from DB are in transient state, not persistent
Thomas,
I've been stepping through the OBJ JDO and JDORI code. I have
determined that the PersistenceCapable objects never are assigned a
StateManager (member jdoStateManager) when they are assembled from a row
result. When an object is created and persisted, it does get assigned a
StateManager, but I see no corresponding assignment for objects fetched
from the DB. At what point should that be happening?
Thomas Mahler wrote:
Hi Ketan,
Ketan Gangatirkar wrote:
All,
I'm having a problem with objects fetched from the database. All JDOs
are treated as Transient objects when they have just been fetched from
the database. Thus, they don't have object ids (.jdoGetObjectId()
returns null) or a reference to a PM (.jdoGetPersistenceManager()
returns null). obj.jdoIsPersistent() and JDOHelper.isPersistent(obj)
both return false (obviously, since they're the same). As a result,
when I setX() on the objects, the PM does not propagate the changes back
to the database even though the object was just loaded from the
database.
Ah, this seems similar to the problem Marko Lahma reported yesterday.
I have one test JSP like this (slightly condensed):
Iterator iterator = pm.getExtent(User.class, false).iterator();
while (iterator.hasNext())
{
User user = (User) iterator.next();
boolean b = JDOHelper.isPersistent(user));
//
}
b is almost always false. Only when user is a newly or recently created
object will it be in the Persistent state. I can fetch it using Extents
or Queries and isPersistent() returns true in that case. At some point,
however, recently inserted objects stop being retrieved as persistent
objects and become like the others. I have not been able to discern a
cause; they seem to expire after a few minutes. Restarting Tomcat
will definitely cause retrieved objects to be treated as transient. I
am using application type persistence, but from what I could gather
from the documentation, that is supported without any special programmer
support.
I have seen several mentions in the list archives for this list of
similar problems, but no resolution. Given that the JDO implementation
would be practically useless without being able to update persistent
JDOs, I am certain that this is user error, but after spending a whole
day trying to track this down, I am out of ideas. I would greatly
appreciate a pointer in the right direction.
From what you describe I assume it is a bug. I'll try to fix it asap.
cheers,
Thomas
More details:
As far as configuration goes, I am using default OBJ.properties
settings. I have verified my repository_user.xml and *.jdo files. I am
not using any of the internal tables because I am not using any of the
features for which it is required.
Software packages I am using:
DB-OJB 1.0 RC3 (could not build RC4)
Tomcat 4.1.something (WinXP)
JDK 1.4.2 (WinXP)
J2EE 1.3.1 (WinXP)
PostgreSQL 7.3.3 (on FreeBSD)
Things I have tried:
Defining my own object id class
Using a single, static instance of PersistenceManager instead of going
to PersistenceManagerFactory multiple times
Fiddling with the location of the queries in the transaction
Obtaining JDOs via Extents vs. Queries
forcing cache reloads with evict() and refresh()
-
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: JDO - Objects fetched from DB are in transient state, not persistent
Hi Ketan,
Ketan Gangatirkar wrote:
Thomas,
I've been stepping through the OBJ JDO and JDORI code. I have
determined that the PersistenceCapable objects never are assigned a
StateManager (member jdoStateManager) when they are assembled from a row
result.
That's exactly the problem! I'm currently researching how to solve this
issue.
When an object is created and persisted, it does get assigned a
StateManager, but I see no corresponding assignment for objects fetched
from the DB.
I does does happen when objects are retrieved by Identity in
OjbStoreManager.fetch.
But it does not happen when loading object via a query or a whole Extent.
I'm currently trying to implement the StateManager assignment in
OjbExtent too. But it's not as easy as I hoped...
I'll need a closer look at the JDORI again...
cheers,
Thomas
At what point should that be happening?
Thomas Mahler wrote:
Hi Ketan,
Ketan Gangatirkar wrote:
All,
I'm having a problem with objects fetched from the database. All JDOs
are treated as Transient objects when they have just been fetched from
the database. Thus, they don't have object ids (.jdoGetObjectId()
returns null) or a reference to a PM (.jdoGetPersistenceManager()
returns null). obj.jdoIsPersistent() and JDOHelper.isPersistent(obj)
both return false (obviously, since they're the same). As a result,
when I setX() on the objects, the PM does not propagate the changes back
to the database even though the object was just loaded from the
database.
Ah, this seems similar to the problem Marko Lahma reported yesterday.
I have one test JSP like this (slightly condensed):
Iterator iterator = pm.getExtent(User.class, false).iterator();
while (iterator.hasNext())
{
User user = (User) iterator.next();
boolean b = JDOHelper.isPersistent(user));
//
}
b is almost always false. Only when user is a newly or recently created
object will it be in the Persistent state. I can fetch it using Extents
or Queries and isPersistent() returns true in that case. At some point,
however, recently inserted objects stop being retrieved as persistent
objects and become like the others. I have not been able to discern a
cause; they seem to expire after a few minutes. Restarting Tomcat
will definitely cause retrieved objects to be treated as transient. I
am using application type persistence, but from what I could gather
from the documentation, that is supported without any special programmer
support.
I have seen several mentions in the list archives for this list of
similar problems, but no resolution. Given that the JDO implementation
would be practically useless without being able to update persistent
JDOs, I am certain that this is user error, but after spending a whole
day trying to track this down, I am out of ideas. I would greatly
appreciate a pointer in the right direction.
From what you describe I assume it is a bug. I'll try to fix it asap.
cheers,
Thomas
More details:
As far as configuration goes, I am using default OBJ.properties
settings. I have verified my repository_user.xml and *.jdo files. I am
not using any of the internal tables because I am not using any of the
features for which it is required.
Software packages I am using:
DB-OJB 1.0 RC3 (could not build RC4)
Tomcat 4.1.something (WinXP)
JDK 1.4.2 (WinXP)
J2EE 1.3.1 (WinXP)
PostgreSQL 7.3.3 (on FreeBSD)
Things I have tried:
Defining my own object id class
Using a single, static instance of PersistenceManager instead of going
to PersistenceManagerFactory multiple times
Fiddling with the location of the queries in the transaction
Obtaining JDOs via Extents vs. Queries
forcing cache reloads with evict() and refresh()
-
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: JDO - Objects fetched from DB are in transient state, not persistent
Hi Ketan,
Ketan Gangatirkar wrote:
All,
I'm having a problem with objects fetched from the database. All JDOs
are treated as Transient objects when they have just been fetched from
the database. Thus, they don't have object ids (.jdoGetObjectId()
returns null) or a reference to a PM (.jdoGetPersistenceManager()
returns null). obj.jdoIsPersistent() and JDOHelper.isPersistent(obj)
both return false (obviously, since they're the same). As a result,
when I setX() on the objects, the PM does not propagate the changes back
to the database even though the object was just loaded from the
database.
Ah, this seems similar to the problem Marko Lahma reported yesterday.
I have one test JSP like this (slightly condensed):
Iterator iterator = pm.getExtent(User.class, false).iterator();
while (iterator.hasNext())
{
User user = (User) iterator.next();
boolean b = JDOHelper.isPersistent(user));
//
}
b is almost always false. Only when user is a newly or recently created
object will it be in the Persistent state. I can fetch it using Extents
or Queries and isPersistent() returns true in that case. At some point,
however, recently inserted objects stop being retrieved as persistent
objects and become like the others. I have not been able to discern a
cause; they seem to expire after a few minutes. Restarting Tomcat
will definitely cause retrieved objects to be treated as transient. I
am using application type persistence, but from what I could gather
from the documentation, that is supported without any special programmer
support.
I have seen several mentions in the list archives for this list of
similar problems, but no resolution. Given that the JDO implementation
would be practically useless without being able to update persistent
JDOs, I am certain that this is user error, but after spending a whole
day trying to track this down, I am out of ideas. I would greatly
appreciate a pointer in the right direction.
From what you describe I assume it is a bug. I'll try to fix it asap.
cheers,
Thomas
More details:
As far as configuration goes, I am using default OBJ.properties
settings. I have verified my repository_user.xml and *.jdo files. I am
not using any of the internal tables because I am not using any of the
features for which it is required.
Software packages I am using:
DB-OJB 1.0 RC3 (could not build RC4)
Tomcat 4.1.something (WinXP)
JDK 1.4.2 (WinXP)
J2EE 1.3.1 (WinXP)
PostgreSQL 7.3.3 (on FreeBSD)
Things I have tried:
Defining my own object id class
Using a single, static instance of PersistenceManager instead of going
to PersistenceManagerFactory multiple times
Fiddling with the location of the queries in the transaction
Obtaining JDOs via Extents vs. Queries
forcing cache reloads with evict() and refresh()
-
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]
