Re: DListImpl leaks a PB

[Thomas Mahler]

Hi again David,

[EMAIL PROTECTED] wrote:

Well, "remove from the database" may have been too broad a term.  I've
included some of the code, but... we have wrapper around OJB..  I will
summarize our wraper, and perhaps that will help.

StateFactory is going to do a query using ODMG and return what is really a
DListImpl.
Transaction is fairly thin wraper around an OJB Transaction.


       Project project = createProject("Test");

        List stateList = StateFactory.loadAll(repository());

        Transaction t = project.lock(repository());
            /* snip - do something */
        t.commit();

        stateList.remove(0);

Ahh, now I see. The DlistImpl does check if it is bound to a transaction if remove(..) or add(..) is called. if there is a tx is found, the operation is performed against the tx too!
In your case the tx is closed and thus the crash.
I fixed this in CVS. Now we check if there is a tx *and* if it is open before working against the tx!

Thanks for finding this bug!

1) to me, the return from StateFactory is "just a List", and I should be
able to freely manipulate it as such.

I agree.
OJB allows you to configure the Collection return type for OQL queries in OJB.properties. SO if you don't like Dlist, you can also use normal Vectors...

If there is no "currentTransaction",
the the list contents should be changed without ever having any impact on
the persistence of said objects.   Consider the case where I load a bunch
of objects, but I only want to show a subset, I might want to remove from
the list those objects that are not part of that subset.

I agree. The existing code already tried to treat this situation correctly, but the check was not complete!

2) for some reason, OJB thinks there is a "currentTransaction", even though
there shouldn't be.

There is one, but it is closed!

cheers,
Thomas

Either it's an OJB bug, or I have to do something
(other than commit()) to say "this transaction is complete.  Consider me
not to have a current transaction".  What it's doing, because it thinks
there is a current transaction, is allocating a PB from the pool that is
never being freed.

I know this would be easier to understand if I had direct OJB example code,
and I'll code up such a test if necessary (but I'd rather not) have to.

David Corbin



|---------+--------------------------->
|         |           Thomas Mahler   |
|         |           <[EMAIL PROTECTED]|
|         |           >               |
|         |                           |
|         |           12/20/2002 01:38|
|         |           AM              |
|         |           Please respond  |
|         |           to "OJB Users   |
|         |           List"           |
|         |                           |
|---------+--------------------------->
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                                  |
  |        To:      OJB Users List <[EMAIL PROTECTED]>                                                                                     |
  |        cc:                                                                                                                                       |
  |        Subject: Re: DListImpl leaks a PB                                                                                                         |
  |                                                                                                                                                  |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|



Hi David,

[EMAIL PROTECTED] wrote:

I'm running 0.9.4.

I loaded a collection of items (OBJ returned a DListImpl).  I removed an
item from a the list.  For reasons unknown (well, not entirely clear),

OJB

thought there was a current transaction so it proceeded to remove the
object from the database.  Now, I had, in fact, just commited a
transaction.  So, either this is a bug in the committing a transaction

does

not "remove" the current Transaction, or I'm not doing something I'm
supposed to do with Transaction to indicate I'm through with like I'm
supposed to.

Anybody got any ideas which one it is?

I'm not quite sure what's going on in your application exactly. Could
you please post the relevant section of your code producing this problem?

ODMG collections are build to work *within* ODMG transaction boundaries.
That is if you remove an item from such a collection, they will tell the
current transaction about the deletion. But they should not access the
database directly!

cheers,
Thomas

Thanks
David Corbin



This message contains information from Equifax Inc. which may be
confidential and privileged.  If you are not an intended recipient,

please

refrain from any disclosure, copying, distribution or use of this
information and note that such actions are prohibited.  If you have
received this transmission in error, please notify by e-mail
[EMAIL PROTECTED]



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]

For additional commands, e-mail: <mailto:[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>







--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>