Re: [jBoss-Dev] Distributed transactions (Tyrex JBoss)

2001-03-21 Thread Bill Burke
Having a distributed OTS would be great, but don't you have to have distributed EntityBean locking as well to have a complete solution? Let's say you have two instances of Jboss running and they're both trying to use EntityBean A in separate transactions. Shouldn't the bean be locked across

[JBoss-dev] Re: [JBossCMP] why not select for update on entity load?

2001-03-21 Thread Bill Burke
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

[JBoss-dev] JAWS select for update patch

2001-03-22 Thread Bill Burke
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

Re: [JBoss-dev] JDBC provider redundant and XA stuff

2001-03-29 Thread Bill Burke
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

[JBoss-dev] I need ammo

2001-03-29 Thread Bill Burke
to go. Thanks very much in advance, Bill Burke ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] The Weblogic to JBoss/Jetty experience.

2001-04-02 Thread Bill Burke
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

Re: [JBoss-dev] [PROPOSAL] daily builds?

2001-04-03 Thread Bill Burke
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

Re: [JBoss-dev] [ jboss-Patches-414023 ] rewrite minerva statement

2001-04-05 Thread Bill Burke
=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

[JBoss-dev] JdbcProvider removal

2001-04-05 Thread Bill Burke
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

Re: [JBoss-dev] snapshot of load bug?

2001-04-10 Thread Bill Burke
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

Re: [JBoss-dev] build.bat fails for Windows

2001-04-11 Thread Bill Burke
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

RE: [JBoss-dev] DependencyManager jboss.dependencies

2001-04-13 Thread Bill Burke
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]

RE: [JBoss-dev] [ jboss-Change Notes-416812 ] Removed res-jndi-namejava: prefix need

2001-04-17 Thread Bill Burke
Yup, Especially those of us that are using direct SQL calls using the connection pools. Am I correct here? Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of danch Sent: Tuesday, April 17, 2001 4:09 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev]

[JBoss-dev] why is Home lookup an RMI call?

2001-04-18 Thread Bill Burke
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

RE: [JBoss-dev] why is Home lookup an RMI call?

2001-04-18 Thread Bill Burke
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

RE: [JBoss-dev] TODO: JBossCMP 1.1 FAST!

2001-05-07 Thread Bill Burke
BTW, running with tuned updates off is really, really, bad. With tuned updates off, CMP will update your primary keys as well. Updating primary keys is a crazy thing to do because the database needs to obtain write-locks on any indexes/constraints attached to that row/table. This can cause

RE: [JBoss-dev] TODO: JBossCMP 1.1 FAST!

2001-05-07 Thread Bill Burke
-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

RE: [JBoss-dev] TODO: JBossCMP 1.1 FAST!

2001-05-08 Thread Bill Burke
]]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

RE: [JBoss-dev] TODO: JBossCMP 1.1 FAST!

2001-05-08 Thread Bill Burke
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

RE: [JBoss-dev] Caching - Locking - Server Dies!

2001-06-04 Thread 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:

RE: [JBoss-dev] Using of JBoss in the real world

2001-06-04 Thread Bill Burke
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

RE: [JBoss-dev] Fw: Caching - Locking - Server Dies!

2001-06-04 Thread Bill Burke
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:

RE: [JBoss-dev] Caching - Locking - Server Dies!

2001-06-05 Thread Bill Burke
-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

RE: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans)

2001-06-06 Thread Bill Burke
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

RE: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans)

2001-06-06 Thread Bill Burke
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

RE: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans)

2001-06-06 Thread Bill Burke
/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

[JBoss-dev] NoCachePolicy

2001-06-06 Thread Bill Burke
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

RE: [JBoss-dev] race condition between EntityInstanceInterceptor and InstanceSynchronization?

2001-06-07 Thread Bill Burke
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

RE: [JBoss-dev] race condition between EntityInstanceInterceptor and InstanceSynchronization?

2001-06-07 Thread Bill Burke
? Bill Burke wrote: Another possible bug related to this same problem. [please read below]. EntityInstanceInterceptor gets the mutex of the Entity's key before going into the do..while loop. If a different thread/transaction rollsback, the mutex gets detached from

RE: [JBoss-dev] race condition between EntityInstanceInterceptor and InstanceSynchronization?

2001-06-07 Thread Bill Burke
: [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

RE: [JBoss-dev] CMP fields XML Serialization

2001-06-08 Thread Bill Burke
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

RE: [JBoss-dev] FW: Busy wait on one thread

2001-06-10 Thread Bill Burke
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

RE: [JBoss-dev] FW: Busy wait on one thread

2001-06-11 Thread Bill Burke
-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

RE: [JBoss-dev] FW: Busy wait on one thread

2001-06-11 Thread Bill Burke
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

RE: [JBoss-dev] FW: Busy wait on one thread

2001-06-11 Thread Bill Burke
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

RE: [JBoss-dev] FW: Busy wait on one thread

2001-06-11 Thread Bill Burke
|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

RE: [JBoss-dev] FW: Busy wait on one thread

2001-06-11 Thread Bill Burke
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

[JBoss-dev] Screwed up: commited into mainline by mistake

2001-06-11 Thread Bill Burke
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

RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins EntitySynchronizationInterceptor.java EntityInstanceInterceptor.java EntityInstanceCache.java AbstractInstanceCache.java

2001-06-11 Thread Bill Burke
-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

RE: [JBoss-dev] Screwed up: commited into mainline by mistake

2001-06-11 Thread Bill Burke
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

RE: [JBoss-dev] race condition in EntityInstanceInterceptor FIXED?

2001-06-11 Thread Bill Burke
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

RE: [JBoss-dev] race condition between EntityInstanceInterceptor and InstanceSynchronization?

2001-06-11 Thread Bill Burke
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

[JBoss-dev] Should storeEntity be called after every invocation?

2001-06-13 Thread Bill Burke
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 =

[JBoss-dev] FYI: Race conditions reported exist, but are not sooo bad

2001-06-13 Thread Bill Burke
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

RE: [JBoss-dev] Re: [JBossCMP] Should storeEntity be called after every invocation?

2001-06-13 Thread Bill Burke
. 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

RE: [JBoss-dev] Re: [JBossCMP] Should storeEntity be called after every invocation?

2001-06-13 Thread Bill Burke
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

RE: [JBoss-dev] Should CacheKey copy its id on creation?

2001-06-13 Thread Bill Burke
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

RE: [JBoss-dev] Should CacheKey copy its id on creation?

2001-06-13 Thread Bill Burke
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?

RE: [JBoss-dev] Should CacheKey copy its id on creation?

2001-06-13 Thread Bill Burke
-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,

RE: [JBoss-dev] Should CacheKey copy its id on creation?

2001-06-13 Thread Bill Burke
-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

RE: Commit Messages was [RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb CacheKey.java]

2001-06-13 Thread Bill Burke
-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

RE: Commit Messages was [RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb CacheKey.java]

2001-06-13 Thread Bill Burke
-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,

RE: [JBoss-dev] No storeEntity before ejbFindMETHOD

2001-06-13 Thread Bill Burke
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

RE: [JBoss-dev] No storeEntity before ejbFindMETHOD

2001-06-13 Thread Bill Burke
-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

RE: Commit Messages was [RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb CacheKey.java]

2001-06-13 Thread Bill Burke
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:

RE: [JBoss-dev] No storeEntity before ejbFindMETHOD

2001-06-14 Thread Bill Burke
-- | | | | | |-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

RE: [JBoss-dev] please help (Unix port permissions)

2001-06-14 Thread Bill Burke
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

RE: [JBoss-dev] Audit Trail Support

2001-06-14 Thread Bill Burke
-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

RE: [JBoss-dev] No storeEntity before ejbFindMETHOD

2001-06-14 Thread Bill Burke
] |[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

RE: [JBoss-dev] No storeEntity before ejbFindMETHOD

2001-06-14 Thread Bill Burke
-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

RE: [JBoss-dev] No storeEntity before ejbFindMETHOD

2001-06-15 Thread Bill Burke
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

RE: [JBoss-dev] ejbStore() delay seems to be a serious problem

2001-06-17 Thread Bill Burke
-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

RE: [JBoss-dev] ejbStore() delay seems to be a serious problem

2001-06-18 Thread Bill Burke
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

RE: [JBoss-dev] no select-for-update with finder optimization(read-ahead)

2001-06-18 Thread Bill Burke
] 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

[JBoss-dev] What are the real effects of ROWID on performance?

2001-06-18 Thread Bill Burke
Vinay, What effect will ROWIDreally have on performance? Will this feature be in 2.4? TIA, Bill

RE: [JBoss-dev] ejbStore() delay seems to be a serious problem

2001-06-18 Thread Bill Burke
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,

RE: [JBoss-dev] ejbStore() delay seems to be a serious problem

2001-06-18 Thread Bill Burke
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

RE: [JBoss-dev] ejbStore() delay seems to be a serious problem

2001-06-18 Thread Bill Burke
-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

RE: [JBoss-dev] [ jboss-Bugs-434227 ] ejbStore delay can lead toDB corruption

2001-06-18 Thread Bill Burke
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

RE: [JBoss-dev] remote jboss configuration

2001-06-19 Thread Bill Burke
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

RE: [JBoss-dev] [ jboss-Bugs-434227 ] ejbStore delay can lead to DB corruption

2001-06-19 Thread Bill Burke
: 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

RE: [JBoss-dev] EntityInstanceInterceptor blocking when there is no transaction

2001-06-19 Thread Bill Burke
-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

RE: [JBoss-dev] EntityInstanceInterceptor blocking when there is no transaction

2001-06-19 Thread Bill Burke
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

RE: [JBoss-dev] Is findByPrimaryKey optimized enough in JAWS/CMP, even BMP?

2001-06-19 Thread Bill Burke
-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

RE: [JBoss-dev] Is findByPrimaryKey optimized enough in JAWS/CMP, even BMP?

2001-06-19 Thread Bill Burke
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

RE: [JBoss-dev] Is findByPrimaryKey optimized enough in JAWS/CMP, even BMP?

2001-06-20 Thread Bill Burke
-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

[JBoss-dev] Etiquette for branch 2_4 commit?

2001-06-20 Thread Bill Burke
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

[JBoss-dev] finder optimization(read-ahead) phase 3

2001-06-21 Thread Bill Burke
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

RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCFinderCommand.java

2001-06-22 Thread Bill Burke
-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

RE: [JBoss-dev] finder optimization(read-ahead) phase 3

2001-06-22 Thread Bill Burke
-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

[JBoss-dev] When will 2.4 be official?

2001-06-22 Thread Bill Burke
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

RE: [JBoss-dev] finder optimization(read-ahead) phase 3

2001-06-25 Thread Bill Burke
(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

RE: [JBoss-dev] finder optimization(read-ahead) phase 3

2001-06-25 Thread Bill Burke
-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

RE: [JBoss-dev] CVS mysterious, at least for me...

2001-06-25 Thread Bill Burke
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

RE: [JBoss-dev] Entity acquisition bugs

2001-06-25 Thread Bill Burke
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

[JBoss-dev] Can Home references get stale?

2001-06-25 Thread Bill Burke
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

[JBoss-dev] Using SoftReference with pools and caches

2001-06-25 Thread Bill Burke
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

RE: [JBoss-dev] High load...

2001-06-25 Thread Bill Burke
-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

RE: [JBoss-dev] Can Home references get stale?

2001-06-25 Thread Bill Burke
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

RE: [JBoss-dev] Can Home references get stale?

2001-06-25 Thread Bill Burke
- 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

RE: [JBoss-dev] CMP 2.x Quick How-to

2001-06-25 Thread Bill Burke
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

RE: [JBoss-dev] Can Home references get stale?

2001-06-25 Thread Bill Burke
? 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

[JBoss-dev] new Threads.java (cache bug tests) is incomplete.

2001-06-25 Thread Bill Burke
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

RE: [JBoss-dev] Can Home references get stale?

2001-06-25 Thread Bill Burke
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

RE: [JBoss-dev] Can Home references get stale?

2001-06-26 Thread Bill Burke
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

RE: [JBoss-dev] High load...

2001-06-26 Thread Bill Burke
-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

RE: [JBoss-dev] High load...

2001-06-26 Thread Bill Burke
-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

RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java

2001-06-26 Thread Bill Burke
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:

[JBoss-dev] Shouldn't expose transaction-isolation within CMP

2001-06-26 Thread Bill Burke
-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

RE: [JBoss-dev] Shouldn't expose transaction-isolation within CMP

2001-06-26 Thread Bill Burke
-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

  1   2   3   4   5   6   7   8   9   10   >