Bill,
I tried increasing the <resizer-period> to 6000 (10 minutes) so that
the cache wouldn't resize during the load and that seems to have sidestepped
the problem. I was able to load a total of 9919 records with no "INSERTING
AN ALREADY EXISTING BEAN" errors.
I think it's safe to say that there is something fishy going on when
the LRU cache resizes during heavy consecutive ejbCreates for BMPs. This
should at least narrow the problem down a bit and I should be able to
produce a platform-independent test for you soon. I've been side-tracked by
this issue for a few days and I have to make up the lost development time
first.
> What I'm trying to do here is isolate the problem. When you run
into this
> problem, is there only one client hitting JBoss? If this is true,
then the
> > only thing that I can think of is that the passivation thread is trying
> to
> > pacify objects in the cache at the same time you are creating things
> because
> > you have gone over the max.
>
Yes, I only have one client running. It might not be the
passivation thread which is causing the problems though. The server log
showed passivation occurring during the loading process. I think it's the
cache resizing.
> Are you sure that you are solely doing creates? No removes, etc?
No removes but I am performing ejbFinds in between creates.
> Sorry, docs say that setting to 0 disables resizer-period. I
thought it
> would help
This seems like a bug or the documentation may be outdated. I'll
post the question in a separate thread and see what's up with it.
> I've got Win2k/Linux and Oracle. If you could duplicate the
problem with
> InstantDB that would be helpful as well. I need some code to work
with.
I'll try that. If my theory is correct, I should be able to produce
a test case that can use InstantDB.
> What are you using for a PK class? If it is a custom class(not
Integer,
> Long, etc...) could you post it? Or is it too complicated?
I'm an old-school database developer, I like my primary keys
surrogate (serial numbers) and my tables normalized. My PK class is
java.lang.Integer.
> The rollback happened because of "INSERTING AN ALREADY EXISTING
BEAN..."
> correct? Not something else.
As far as I can tell, yes. Executing the rolled-back database
transaction against the database (cut and paste) worked okay.
> No, don't explicity handle the transaction. Everything should
work! This
> exception should not be happening and it is very very bad.
I agree, this is definitely a big problem. Good thing you were able
to point me in the right direction. I already had my BEA quotes in my hand
a few minutes ago! $10,000 per processor?!?!?! Geez.
> Happy to help. This stuff is fundamental and should really be
fullproof.
> There were a lot of holes patched up in 2.4 Beta in regards to
passivation
> and Entity and cache synchronization. In the mainline(2.5), a lot
of it was
> even re-written. If you feel up to it, could you try this on 2.4
Beta or
> 2.5?
I tried 2.4 Beta last week and the problem was still there. I'll
check out 2.5 though maybe it's already fixed.
> We're actually in production with a self-modified JBoss 2.2.2.
The
> modifications we made were the holes I just talked about above
with
> passivation and Entity/cache synchronizations. I've actually seen
the
> "INSERTING AN ALREADY EXISTING BEAN..." exception when doing a lot
of Entity
> removes and creates with Commit option "C". These problems were
fixed by
> the patches in 2.4. Let me know. I really want this to be fixed.
I'll try to make a test case for InstantDB before the week
is out.
Thanks for your help, Bill. At least we have an idea where
the problem is and how to work around it!
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
