I haven't seen an explanation for this, so here goes.
You have never added the new Task to the Summary's taskList, so you
have created an inconsistent object graph: You have a task which
claims to belong to a given summary, but the summary does not
acknowledge the task. When you lock the new Task, OJB happens to
give primacy to the Task's version of reality, and so writes it to
the database. Meanwhile, the Summary object is still in the cache,
so the next time you retrieve it OJB doesn't re-materialize it from
the database, and voila - same list as before. Maintaining the
consistency of your object graph is your job, not OJB's. OJB is just
responsible for getting it into and out of the database.
There are (at least) two possible solutions, short of clearing the
cache after every write operation:
1) Explicitly maintain both directions on your relationship,
e.g. by calling Summary.addTask(Task) which adds to the
collection and then calls Task.setSummary(Summary). This
approach has the benefit that it doesn't rely on any special
behavior in the persistence layer (currently OJB, but next week
who knows?) to maintain the consistency of your in-memory
object graph. Note in the javadoc for Task.setSummary() that
it should not be called directly, or put more interesting logic
in both setSummary() and addTask() to arrange for both pointers
to be set no matter which is called first.
2) Set auto-refresh='true' on the taskList collection-descriptor
in repository.xml. This tells OJB to refetch the contents of
the collection any time that a Summary is retrieved from the
cache. It saves you the trouble of maintaining your
backpointers, but note that it still allows for an inconsistent
graph: If you do your steps 1-3 but never do 4, then your
Summary will continue to have the wrong taskList.
Hope this is helpful.
--
Steve Clark
Technology Applications Team
Natural Resources Research Center/USGS
[EMAIL PROTECTED]
(970)226-9291
>>>>> Wil Hunt writes:
Wil> After going home last night and thinking about this over a
Wil> beer, I realized that either I was high yesterday, or my
Wil> brain ceased to function properly. The description I gave
Wil> was not an accurate portrayal of the problem at hand.
Wil> (Though it would have had similar results if I HAD had the
Wil> problem.)
Wil> Here's what was REALLY going on... (<bonk self>)
Wil> I have two classes Summary and Task. There is a foreign-key
Wil> relationship from Task to Summary such that there are 0..n
Wil> tasks for each summary and one summary per task. In the
Wil> repository.xml I had told OJB to make a collection of Tasks
Wil> per Summary using the inverse foreign-key relationships.
Wil> Step one: Get Summary by primary key. -- No problem.
Wil> Step two: Get taskList by calling collection on returned
Wil> summary. -- No problem.
Wil> Step three: Create new Task that points to the same summary
Wil> -- k.. it's in the DB
Wil> Step four: Get same summary by primary key -- k...
Wil> Step five: Get taskList by calling collection on returned
Wil> summary. This is where I get the same list I got in step
Wil> two.
Wil> I apologize for the confusion. I'm using ODMG calls to
Wil> read/write my db.
Wil> I have temporarily side-stepped this issue by simply removing
Wil> the collection/inverse foreign key lookup and doing a manual
Wil> getTasksBySummaryId lookup instead. I would still love to
Wil> know how to get the above scenario to work. I have a feeling
Wil> that auto-update="object" or something might affect this, but
Wil> I remember reading that when using ODMG, you're supposed to
Wil> leave those settings at the defaults.
Wil> Thanks!
Wil> Wil
"Brian McCallister" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> Odd. Some notes...
>>
>> Task.getClass().getName() works better as Class#toString isn't
>> the class name =(
>>
>> Do you not get ANY objects back, or do you get a different
>> object back form the query?
>>
>> Is the foreign key a primitive type by chance?
>>
>> -Brian
>>
>> On Apr 13, 2004, at 8:20 PM, Wil Hunt wrote:
>>
>> > Hey guys,
>> >
>> > I'm having a problem with regard to OJB-managed objects
>> > and their
>> > visibility. Here's the scenario:
>> >
>> > 1) Create a new object:
>> > Task task = new Task(...); Transaction tx =
>> > _odmg.newTransaction(); tx.begin(); tx.lock(task,
>> > Transaction.WRITE); tx.commit();
>> >
>> > Note: task is saved (successfully) with a foreign key X.
>> >
>> > If I check the database.. the object is there. Good.
>> > 2) Query ODMG:
>> > select tasks from Task.getClass() where fkeyname = X
>> >
>> > This request does not return the above mentioned objects.
>> >
>> > If I restart my server (thus restarting OJB) then the objects
>> > show up in further queries.
>> >
>> > am I missing something obvious?
>> >
>> > Any assistance would be greatly appreciated.
>> >
>> > Thanks!
>> >
>> > Wil
>> >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
Wil> ---------------------------------------------------------------------
Wil> To unsubscribe, e-mail: [EMAIL PROTECTED]
Wil> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
