d by database,
like the type maps), but I think it's a great idea.
On Wed, 21 Mar 2001, Bill Burke wrote:
Hi all,
(Where should I email questions like this? Jboss-Dev, Jboss-User,
JBoss-CMP? Thanks)
Why not have the ability to "select for update" in CMP for an EntityBean
l
Well, one person thought adding "select for update" on Entity Loading to
JAWS would be useful so I looked into it. It's a rather simple change
if anybody thinks it worth adding to CVS(I don't have rw access). I
thought it would be useful to be able to turn "select for update" on or
off for
One more thing on this that I've commented on before.
The Oracle 8.1.7 drivers do connection and statement pooling as well as
XAConnections, so there is no need to use Minerva. Unfortunately,
Minerva does all the work of hooking up the XAResources with the
Transaction Manager and such. It
to go.
Thanks very much in advance,
Bill Burke
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
I've seen some posts here about supporting WebLogic deployment
descriptors, so I thought I should share some of our experiences of
porting a year old Weblogic 5.1 application to JBoss/Jetty. We started
off using JBoss 2.0Final and have recently moved to various snapshots of
JBoss 2.1 as bugs
I'm glad that somebody has finally proposed this. If you need any help,
or don't have the time to do this, we can take it over. I've done this
sort of thing many times.
Regards,
Bill Burke
CommerceTone
Kimpton,C (Chris) wrote:
Hi,
Are there daily builds done of jboss?
Can I
=414023group_id=22866
Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Bill Burke (patriot1burke)
Assigned to: Nobody/Anonymous (nobody)
Summary: rewrite minerva statement caching
Initial Comment:
I rewrote the statement caching in Minerva for a number
of reasons:( tar
Hey Marc,
Still want this done? If so, should I create a task(or Bug?) in SourceForge and
assign it to myself?
BTW, do people still use the old Bugs database? If I'm looking for a little bit of
work, should I look there?
The Sourceforge bugs/tasks, are empty.
Regards,
Bill
marc fleury
Hey Dan,
If you're not going to commit it, could you put the patch on the
SourceForge patches page? I'm really interested in the patch as well,
because I'm doing load testing next week.
Thanks,
Bill
danch wrote:
In the short term, I'll send you a patch. Probably there would be a
JBoss
Hardcode the paths in build.bat and you'll be ok. I had trouble
building with 2.0 and 2.1, I hardcoded the paths, and everything was
fine. Of course I didn't bother to figure out why :-)
Bill
Filip Hanik wrote:
I just checked out a fresh version of the JBoss module.
the build script
It's not used anywhere. Since most mbeans are loaded in order from
jboss.jcml, the DependencyManager is not needed. Am I wrong?
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of marc
fleury
Sent: Friday, April 13, 2001 7:23 PM
To: [EMAIL PROTECTED]
All,
(If this is a
jboss-user question, I apologize.) I've been doing some performance
testing on my code, and I noticed that Home lookups on the InitialContext is
always an RMI call through jnp even though the Naming service is in the same
VM. Maybe this is a configuration problem on my
is Home lookup an RMI call?
As long as you don't have a Context.PROVIDER_URL set in the env
passed to InitialContext or jndi.properties the Context returned is the
RMI implementation object and calls on it should not involve RMI
invocations.
- Original Message -
From: Bill Burke
To: Jboss
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of James
Cook
Sent: Monday, May 07, 2001 5:54 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] TODO: JBossCMP 1.1 FAST!
- Original Message -
From: Bill Burke [EMAIL PROTECTED]
The point
]]On
Behalf Of Bill
Burke
It's very easy to get deadlock.
Table Apple:
apple_prim_key Number
apple_data1 varchar(256)
apple_data2 Number
Table Pear:
pear_prim_key Number
pear_apple_id Number (indexed/secondary key
constraint to Apple table. Not
sure of the correct
on that column then it will no longer need to do
this. I have
a book somewhere that speaks to this issue, but can't seem to put my hands
on it right now, I've pasted in a URL with this info for you...
http://osi.oracle.com/~tkyte/unindex/
Cheers
Jay
-Original Message-
From: Bill Burke
If an
Entity is loaded within a transaction it is locked until the transaction
completes.
Bill
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of K.V.
Vinay MenonSent: Monday, June 04, 2001 12:59 PMTo: User
@ JBoss; Dev @ JBossSubject:
send details of the kind of
applications you have deployed, the kind of database access it does
[proportion of read only vs transactional data] and the application
architecture overall.
Cheers,
Vinay
- Original Message -
From: Bill Burke [EMAIL PROTECTED]
To: [EMAIL PROTECTED
For
stateless and stateful beans the default transaction mode is
Required.
Bill
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of K.V.
Vinay MenonSent: Monday, June 04, 2001 1:19 PMTo: User @
JBoss; Dev @ JBossSubject: [JBoss-dev] Fw:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of danch
Sent: Tuesday, June 05, 2001 1:38 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Caching - Locking - Server Dies!
Bill Burke wrote:
[snip]
IMHO, there should be an option to remove
I remember Marc talking about this issue awhile back. He said the best
performance would be to have the wait within a loop with a 5 second wait.
while (!locked()) // pseudo code
{
this.wait(5000);
if (!locked())
{
log.(LOCKING-WAITING);
}
}
Regards,
Bill
to Georg's 'wait(DEADLOCKTIMEOUT +
1000)'. Did Marc talk about waiting on 'this'? or is that non-literal?
Bill Burke wrote:
I remember Marc talking about this issue awhile back. He said the best
performance would be to have the wait within a loop with a 5
second wait.
while (!locked
/notify (was Re: [JBoss-dev] Avoiding Locks for
READ-ONLY Beans)
Hi,
Bill Burke wrote:
It's not this same. Basically you have a loop to check to see if the
transaction has been commited or unlocked, but you put a wait of 5
seconds
in there. After the 5 seconds if you're still
If I wanted to write
a NoCachePolicy for EntityBeans (that is, no entity instance caching).
Would it be as simple as implementing CachePolicy where get(..) just returns
null?
TIA,
Bill
should consider adding the
Missing wait/notify and remove that buggy do..while loop as well.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
Burke
Sent: Wednesday, June 06, 2001 9:39 PM
To: Jboss-Development@Lists. Sourceforge. Net
: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
Burke
Sent: Thursday, June 07, 2001 11:42 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] race condition between
EntityInstanceInterceptor and InstanceSynchronization?
-Original Message-
From: [EMAIL PROTECTED
Can you plug-in how a CMP field is stored in the database? If not, this
would be the best first step.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Vincent Harcq
Sent: Friday, June 08, 2001 3:23 AM
To: Dev JBoss
Subject: [JBoss-dev] CMP
Marc,
I've rewritten EntityInstanceInterceptor a little(see my race condition fix
email please) and put it some code so that LOCKING-WAITING isn't printed a
zillion times. I also added a Thread.yield() before continue; in the
lock-do-while-loop.
I've also started looking into ditching the
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Georg
Rehfeld
Sent: Monday, June 11, 2001 8:49 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] FW: Busy wait on one thread
Hi Bill,
I've rewritten EntityInstanceInterceptor a little(see my
and the
locking strategy...
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of danch
|Sent: Monday, June 11, 2001 12:40 PM
|To: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] FW: Busy wait on one thread
|
|
|Bill Burke wrote:
|
| Marc
Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
|Burke
|Sent: Monday, June 11, 2001 11:44 AM
|To: [EMAIL PROTECTED]
|Subject: RE: [JBoss-dev] FW: Busy wait on one thread
|
|
|
|
| -Original Message-
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL
|Christopherson
|Sent: Monday, June 11, 2001 2:01 PM
|To: [EMAIL PROTECTED]
|Subject: RE: [JBoss-dev] FW: Busy wait on one thread
|
|
|On Mon, 11 Jun 2001, Bill Burke wrote:
|
|
| Again, IMHO, these race condition fixes can't wait until JBoss
|3.0 since it
| sounds like 3.0 won't be ready
Wait a minute
Should I check into JBoss 3.0 branch? The mainline(which is 2.4, 2.3???).
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
Burke
Sent: Monday, June 11, 2001 3:00 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] FW
I commited into the
mainline by mistake instead of the JBoss 3.0 (Rabbithole) branch. I'm
sorry I'm such an idiot. I'm unfamiliar with CVS and have been using
WinCVS. I thought if I checkedout stuff from a branch, WinCVS
wouldautomaticallycommit to that same branch.
What do you all want
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of marc
fleury
Sent: Monday, June 11, 2001 4:08 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] CVS update:
jboss/src/main/org/jboss/ejb/plugins
EntitySynchronizationInterceptor.java
PROTECTED]
Subject: Re: [JBoss-dev] Screwed up: commited into mainline by mistake
Since it was going to be commited to main just leave it.
- Original Message -
From: Bill Burke [EMAIL PROTECTED]
To: Jboss-Development@Lists. Sourceforge. Net
[EMAIL PROTECTED]
Sent: Monday, June 11, 2001 1
hands on your changes.
I'm sure my environment would make a good test case for your code.
thanks
-dom
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
Burke
Sent: Monday, June 11, 2001 9:09 AM
To: Jboss-Development@Lists. Sourceforge. Net
Yes, it is checked into the mainline
org.jboss.ejb.plugins:
EntityInstanceCache.java
EntityInstanceInterceptor.java
AbstractInstanceCache.java
BeanSemaphore.java
EntitySynchronizationInterceptor.java
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
All,
We have the following (bad?) assumption in our application code:
begin transaction
Bean b = findByPrimaryKey(...)
System.out.println(flag = + b.getFlag()); // prints flag = 1
b.setFlag(0)
Enumeration = findByAllBeansWithFlagEqualToOne() // where flag =
FYI,
Although they do
exist(I tested for them), the race conditions I reported and fixed in
EntityInstanceInterceptor and EntitySynchronizationInterceptor were NOT the
reason our InstanceCache was getting corrupted. Our InstanceCache was
being corrupted because we had Optimized = true in
.
Bill
-danch
Bill Burke wrote:
All,
We have the following (bad?) assumption in our application code:
begin transaction
Bean b = findByPrimaryKey(...)
System.out.println(flag = + b.getFlag()); // prints flag = 1
b.setFlag(0)
Enumeration
at some point after a
business method is called. The text may be more specific, but I haven't
time to hunt right now.
-danch
Bill Burke wrote:
All,
We have the following (bad?) assumption in our application code:
begin transaction
Bean b
Yeah, sorry, Outlook seems to do this sometimes without warning
2- see below
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
Burke
Sent: Wednesday, June 13, 2001 8:47 AM
To: Jboss-Development@Lists. Sourceforge. Net
Subject: [JBoss-dev
My bad, I didn't look hard enough.
Forgive me? :-)
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
M Stark
Sent: Wednesday, June 13, 2001 1:22 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Should CacheKey copy its id on creation?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of marc
fleury
Sent: Wednesday, June 13, 2001 1:29 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Should CacheKey copy its id on creation?
| 2- you share the same instance of the PrimaryKey, yes,
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of marc
fleury
Sent: Wednesday, June 13, 2001 2:23 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Should CacheKey copy its id on creation?
|BTW, it's only a code bug in our application because we
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of marc
fleury
Sent: Wednesday, June 13, 2001 5:26 PM
To: [EMAIL PROTECTED]
Subject: Commit Messages was [RE: [JBoss-dev] CVS update:
jboss/src/main/org/jboss/ejb CacheKey.java]
also add yourself
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Schaefer, Andreas
Sent: Wednesday, June 13, 2001 6:25 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Commit Messages was [RE: [JBoss-dev] CVS update:
jboss/src/main/org/jboss/ejb CacheKey.java]
Yes,
popular rap song --
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
|Burke
|Sent: Wednesday, June 13, 2001 5:33 PM
|To: Jboss-Development@Lists. Sourceforge. Net
|Subject: [JBoss-dev] No storeEntity before
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of marc
fleury
Sent: Wednesday, June 13, 2001 6:58 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] No storeEntity before ejbFindMETHOD
|boolean dirty = true;
|if (isModified != null)
|{
| try
I don't know how many people use emacs, but how about a common java-mode?
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tahir
Awan
Sent: Wednesday, June 13, 2001 8:25 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Commit Messages was [RE:
--
|
|
|
|
| |-Original Message-
| |From: [EMAIL PROTECTED]
| |[mailto:[EMAIL PROTECTED]]On
Behalf Of Bill
| |Burke
| |Sent: Wednesday, June 13, 2001 5:33 PM
| |To: Jboss-Development@Lists. Sourceforge. Net
| |Subject: [JBoss-dev] No storeEntity before ejbFindMETHOD
| |
| |
| |The EJB spec 2.0 reads
From our sys admin, Ed Marshall, not sure if it works or not, :-)
Requirements: 2.4.x kernel (for distributions, Red Hat 7.1, SuSE 7.1, and I
*think* Mandrake 8.0 should satisfy this) and the iptables
command.
The following is the magic command line:
iptables -t nat -A PREROUTING -p
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of James
Cook
Sent: Wednesday, June 13, 2001 9:00 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Audit Trail Support
Really cool stuff! This can be easily implemented in CMP/JAWS since JAWS
keeps
]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
|Burke
|Sent: Thursday, June 14, 2001 9:55 AM
|To: [EMAIL PROTECTED]
|Subject: RE: [JBoss-dev] No storeEntity before ejbFindMETHOD
|
|
|SoI'll check this stuff in??
Yes, with the understanding that if the user doesn't define
isModified
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of marc
fleury
Sent: Thursday, June 14, 2001 2:48 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] No storeEntity before ejbFindMETHOD
|Yeah, double serialization, but isn't keeping an isUpdated
Gina,
Why don't you bring up a SQL*PLUS window and try it yourself instead of
quoting Oracle manuals. My own experiments with SQL*PLUS and jdbc DO NOT
verify your claims. BTW, I'm on Oracle 8.1.7. Maybe older versions work
differently.
Bill
-Original Message-
From: [EMAIL
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of David
Jencks
Sent: Saturday, June 16, 2001 8:06 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
Hi,
A couple of comments
1. I think the worst
PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
Burke
Sent: Sunday, June 17, 2001 10:23 AM
1. Change JBoss to expose a flush method.
A.setAddress(newAddress)
((ImaginaryJBossEntityProxy)A).flush(); // Causes an ejbStore()/Update.
oldAddress.remove();
This might be the best
] no select-for-update with finder
optimization(read-ahead)
Ya, I realized I'd missed that right after I committed. If you want to
get that in there, go ahead.
thanks,
danch
Bill Burke wrote:
Danch,
Great work on the finder optimization stuff. Our project really needs
this feature
Vinay,
What effect will
ROWIDreally have on performance? Will this feature be in
2.4?
TIA,
Bill
You need to make sure you got the latest from CVS for every file. Also do a
build clean then build dist. It seems like you have some old class files
someplace.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of David
Esposito
Sent: Monday,
Is this kludgy? Yes, but you don't have to worry about it ever not working
unless the EJB spec changes. The EJB Spec requires that all entities of the
same type of a finder get synchronized with the database before the finder
executes. (See section 9.6.4).
Add the finder workaround to the
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Aaron
Mulder
Sent: Monday, June 18, 2001 2:04 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] ejbStore() delay seems to be a serious problem
On Mon, 18 Jun 2001, Bill Burke wrote
You'd have the same type of problems with BMP, wouldn't you?
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jay
Walters
Sent: Monday, June 18, 2001 3:35 PM
To: '[EMAIL PROTECTED]'
Subject: RE: [JBoss-dev] [ jboss-Bugs-434227 ] ejbStore
Even better, provide a URL. And support http, https, file, etc...We have to
manage 3 Instances of JBoss and its a real pain in the ass to manage 3 sets
of config files. This is only going to become worse as we scale up more.
marc,
I'm interested in any new config stuff you're doing that could
:
Seems like an application requiring a CMP Persistence Manager and EJB
container to execute SQL in a specific order might be asking a
bit much to
me...
and Bill Burke replied:
You'd have the same type of problems with BMP, wouldn't you?
Sorry G's, I still can't see the point here
-Original Message-
From: Bill Burke [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 19, 2001 11:40 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] EntityInstanceInterceptor blocking when there
is no transaction
I'm pretty sure the original intent of this code was to lock
I'm pretty sure the original intent of this code was to lock on any method
invocation if the bean already belongs to a different transaction.
Also, take a look at EntitySynchronizationInterceptor. It will call
storeEntity if the method does not belong to a transaction. Since JBoss
does not
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of danch
(Dan Christopherson)
Sent: Tuesday, June 19, 2001 11:42 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Is findByPrimaryKey optimized enough in
JAWS/CMP, even BMP?
Bill Burke wrote
The
optimization would still work within the same transaction.
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Vincent HarcqSent: Tuesday, June 19, 2001 12:00
PMTo: [EMAIL PROTECTED]Subject:
RE: [JBoss-dev] Is findByPrimaryKey
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Aaron
Mulder
Sent: Wednesday, June 20, 2001 8:33 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Is findByPrimaryKey optimized enough in
JAWS/CMP, even BMP?
On Tue, 19 Jun 2001, Bill Burke wrote
I just commited some
minor change to the 2.4 branch. I don't have to ask any permission do I?
if it really is minor(better error messages, in my
instance).
Thanks,
Bill
All,
Building off of
danch's great work, I extended the read-ahead feature of
CMP/JAWS
New
features:
* the read-ahead
flag is defaultable in standardjaws.xml and jaws.xml
* The finder SQL
select call and the LoadEntities SQL select call are now combined. Instead
of 2 sql calls they
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of danch
(Dan Christopherson)
Sent: Thursday, June 21, 2001 6:35 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] CVS update:
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCFinderCommand.java
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of danch
Sent: Thursday, June 21, 2001 11:31 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] finder optimization(read-ahead) phase 3
I mentioned in another email that this didn't seem to work for
I want to move our
production service to a "stable" official 2.4 and need to plan time to do
it.
Any guestimates
would be greatly appreciated.
TIA,
Bill
(read-ahead) phase 3
Bill Burke wrote:
Can you explain this again in other words? I'm kind of
confused. Are you
saying you don't want to have a hashMap of preloaded data per
transaction?
But just one global cache? I think that is a bad idea. I'll
clarify more
if this is what
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of danch
Sent: Monday, June 25, 2001 12:17 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] finder optimization(read-ahead) phase 3
Bill Burke wrote:
Can you explain this again in other
at
src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCFindEntityCommand.jav
a as an example where you can see that the latest contribution
(findByPrimaryKey may now do a read-ahead depending on
configuration by Bill Burke) is made on the main branch and not
2.4 branch.
I'll move the code from HEAD
Marc,
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of marc
fleury
Sent: Sunday, June 24, 2001 6:00 PM
To: Jboss-Development@Lists. Sourceforge. Net
Subject: [JBoss-dev] Entity acquisition bugs
Ok,
bill, saw your comments in teh code and the
We save a reference
to our homes in a static variable in various classes so that we don't have to
keep looking it up.
--
class
SomeClass
{
public static
MyBeanHome myBeanHome = null;
public void
init()
{
InitialContext ctx =
new InitialContext();
myBeanHome
Has anybody thought
about or the implications of using java.lang.ref.SoftReferences in Bean
InstancePools? I think this would be benefitial to put in. Anybody
have any thoughts about this?
Our app, for
instance, has a high probability of hitting the JVMs max memory available
because of
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of marc
fleury
Sent: Monday, June 25, 2001 12:50 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] High load...
|You should try this on some other OSes. I believe that the sun
vm on linux
|uses a
by value
semantics.
Does this consistently happen days after the home was originally obtained?
- Original Message -
From: Bill Burke [EMAIL PROTECTED]
To: Jboss-Development@Lists. Sourceforge. Net
[EMAIL PROTECTED]
Sent: Monday, June 25, 2001 8:16 AM
Subject: [JBoss-dev] Can Home
-
From: Bill Burke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 25, 2001 2:54 PM
Subject: RE: [JBoss-dev] Can Home references get stale?
We have repeated the problem.
Any ideas?
Thanks,
Bill
___
Jboss-development
Dain,
I've read your email on how to use the eager/lazy loading features. I'm not
sure if this is the same thing as danch's read-ahead feature. Your
eager/lazy loading seems to be focused around LoadEntity, where danch's
read-ahead happens on the finder call itself. I really should examine
?
The exception is probably occurring in the server and caught in the client
with the trace lost during serialization. Just a hunch.
--jason
On Mon, 25 Jun 2001, Bill Burke wrote:
I wish I could get a better stack trace. I probably wouldn't
be begging for
help if I could.
No, I keep getting
Marc,
Don't get annoyed
with me, but your new threads test is incomplete:
-You need to
also randomize on the bean's primary key. I say this because some of the
cache bugs I encountered were as a result of one thread throwing a context back
into the InstancePool(via a rollback or
On Mon, 25 Jun 2001, Bill Burke wrote:
FYI,
Everything is within JVM.
Thanks for the help,
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
Behalf Of Jason
Dillon
Sent: Monday, June 25, 2001 8:09 PM
To: [EMAIL PROTECTED
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Can Home references get stale?
Maybe, what version of the server are you running?
- Original Message -
From: Bill Burke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 25, 2001 7:23 PM
Subject: RE: [JBoss-dev] Can Home
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Georg
Rehfeld
Sent: Tuesday, June 26, 2001 11:25 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] High load...
Hi,
Bill:
|- Somebody had a great idea earlier of adding optimistic locking for
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of marc
fleury
Sent: Tuesday, June 26, 2001 1:28 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] High load...
|Sorry Georg, I don't what planet I was on when I made the option A with
|optimistic
Dain,
I really don't think this will work. Please see my previous email.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, June 26, 2001 2:32 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] CVS update:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Dain
Sundstrom
Sent: Tuesday, June 26, 2001 2:20 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] High load...
we would have to implement the transaction isolation levels correctly in
jboss
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of marc
fleury
Sent: Tuesday, June 26, 2001 3:05 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Shouldn't expose transaction-isolation within
CMP
|Please correct me if I'm
I disagreewell, at least for our app, we have transactions where some
entities really need to be serialized and other entities within the
transaction are just fine with read_committed.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of David
Why can't a transaction manage different resources and each of those
resources use a different transaction-isolation level? What's wrong with
that?
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of David
Jencks
Sent: Tuesday, June 26, 2001 5:38
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of danch
Sent: Tuesday, June 26, 2001 6:31 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] High load...
marc fleury wrote:
|But if they're in the same transaction, they must use the same
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of David
Jencks
Sent: Tuesday, June 26, 2001 6:57 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] High load...
Hi,
Ok, I was thinking of within one db. I'm working on a logical
inconsistency
1 - 100 of 1981 matches
Mail list logo
