[JBoss-dev] JBoss Website Issue.
Hello guys, Did anyone notice that the navigation menu on the left hand side of the JBoss.org site does not work when the user is in the survey module? The links are all incorrect since the context seems to have changed to 'survey' and all links are relative to the context. Regards Vinay ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX service architecture: next gen++
What if an interceptor in the stack has a call back to a previous
interceptor that was removed as a result of the update? Maintain multiple
version of the stack until all old references complete?
- Original Message -
From: "Rickard Öberg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 02, 2001 3:20 PM
Subject: Re: [JBoss-dev] JMX service architecture: next gen++
> marc fleury wrote:
>
> > a stack of ObjectNames and in each "message interceptor mbean" there is
a
> >
> > ObjectName name = message.getNextInterceptorInStack();
> > server.invoke(name, mi) // equivalent dynamic invocation
> > ...
> >
> > whatever there are tons of ways to do that (maybe self contained in MI)
>
>
> Good point. I had missed the "send stack along in invoke" option. That
> is indeed superior. Very lightweight and simple.
>
> The stack could indeed done as:
> class InterceptorStack
> {
>List interceptors;
>int idx = 0;
>InterceptorStack(List aList)
>{
> interceptors=aList;
>}
>
>ObjectName getNextInterceptor()
>{
> return (ObjectName)interceptors.get(idx++);
>}
> }
> ---
> So many MI's would be sharing the same list, but with different indices
> into it.
>
> Updating the list would be to simply replace it at the gates. MI's
> already in progress using the old version get to finish with that old
> version.
>
> Nice.
>
> /Rickard
>
> --
> Rickard Öberg
> Software Development Specialist
> xlurc - Xpedio Linköping Ubiquitous Research Center
> Author of "Mastering RMI"
> Email: [EMAIL PROTECTED]
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] NOWAIT Option
Hello Guys, Sometime back I'd posted a query about being able to specify a NOWAIT / WAIT option for the 'select-for-update' bean level option. The change I'd suggested was simply to 1. Add a wait-option field in the jaws.xml file that held the exact string that was used to specify the wait option and gets appended to the select for update sql 2. Load this in the JawsEntityMetaData 3. Check for it and add it in the JDBCLoadEntityCommand. Does this sound sensible or completely off? Regards Vinay ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss Integration
Hello Folks, Have seen quite a few emails fly around regarding JBoss - Resin integration at a VM level and was wondering if something of this sort has already been done. If so can you please share it. If it has not been done is anyone who's played around with Resin for a while and have CVS access for Resin [and have the time and inclination !!] please let me know if they'd be interested in doing this with me getting the JBoss bits done? It should be fun. Any takers? Please mail me at [EMAIL PROTECTED] Thanks in advance, Vinay ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Enhydra vs. JBoss
And has do we have any specifics on Orion vs JBoss? There have been suggestions that it is a decent offering. anyone thoughts? Vinay - Original Message - From: marc fleury To: [EMAIL PROTECTED] Sent: Wednesday, August 29, 2001 5:26 PM Subject: RE: [JBoss-dev] Enhydra vs. JBoss I am going to post an editorial online soon, debunking some of the marketing they have been doing. marcf -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill BurkeSent: Wednesday, August 29, 2001 12:23 PMTo: Jboss-Development@Lists. Sourceforge. NetSubject: [JBoss-dev] Enhydra vs. JBoss From reading the IBD article, is Enhydra a competitor of JBoss? I went to their web site and it seemed that Enhydra really wasn't "Open Source", but a J2EE implementation that came with the source. If they are a competitor in the Open Source arena, how can we kick their ass? Or maybe we already do? Bill
[JBoss-dev] Datasources and the java:/ namespace
Hello Folks, Is there any specific reason we have the jdbc datasources bound under java:/ as opposed to java:/comp/env/jdbc/ ? Regards, Vinay Menon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] NOWAIT option
Hello, Had made a little change to JawsEntityMetaData and the JDBCLoad thingey to support the NOWAIT, select for update option. Worthwhile if I post the change here? The idea is simple 1. Have a field in jaws.xml called 2. Don't specify it if you don't need anything special. If you want a no wait option specify it as NOWAIT or any other option that is dbms specific 3. In the LoadEntityCommand append this text to the select for update sql if has been specified to be true. Vinay ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Select for update : Question for Bill
IMHO, We could simply externalize this in the jaws.xml file with a wait-option tag. Works and is simple. Vinay - Original Message - From: "Vinay Menon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, August 06, 2001 6:01 PM Subject: Re: [JBoss-dev] Select for update : Question for Bill > Thanks! > I'll give it a shot. > > Vinay > - Original Message - > From: "Bill Burke" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, August 06, 2001 3:15 PM > Subject: RE: [JBoss-dev] Select for update : Question for Bill > > > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Vinay > > > Menon > > > Sent: Saturday, August 04, 2001 11:31 AM > > > To: [EMAIL PROTECTED] > > > Subject: [JBoss-dev] Select for update : Question for Bill > > > > > > > > > Hello Bill, > > > Apologies for not following this up earlier than this but I > > > was going to > > > take a look at the no wait option for select for update > > > operations. First of > > > all is the select for update dynamic? i.e. can I start off in regular > mode > > > and then come back and load the same bean in a select for update mode? > > > > No it is not dynamic. I don't think it should be. If it was you would > have > > to expose jboss internals to the application logic and that is not > portable > > across J2EE apps. > > > > > What I am looking for is simply the option to specify the wait > option. > > > May be a flag in jaws.xml to specify this on a per > > > dbms type - > > > in oracle its no wait - not sure what it is called in others. What do > you > > > think? > > > > > > > What do you think of these ideas? What I wanted to do was extend the > > database typemappings in standardjaws.xml. > > > > > > > > Oracle8 > > true > > ![CDATA[SELECT %i FROM %t WHERE %w FOR > > UPDATE]] > > true > > ![CDATA[SELECT %i FROM %t WHERE %w FOR > > UPDATE NOWAIT ]] > > java.lang.Boolean > > BIT > > SMALLINT > > > > > > where "%i" is the items to be select, "%t" is the tablename, and "%w" is > the > > where clause. If a bean turns on select-for-update and it is not > supported > > by the type-mapping, then an exception should be thrown on deployment. > > Maybe your rowid thingy should be put in there as well in the same manner. > > > > And then in jaws.xml > > > > true > > > > Bill > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Select for update : Question for Bill
Thanks! I'll give it a shot. Vinay - Original Message - From: "Bill Burke" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, August 06, 2001 3:15 PM Subject: RE: [JBoss-dev] Select for update : Question for Bill > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Vinay > > Menon > > Sent: Saturday, August 04, 2001 11:31 AM > > To: [EMAIL PROTECTED] > > Subject: [JBoss-dev] Select for update : Question for Bill > > > > > > Hello Bill, > > Apologies for not following this up earlier than this but I > > was going to > > take a look at the no wait option for select for update > > operations. First of > > all is the select for update dynamic? i.e. can I start off in regular mode > > and then come back and load the same bean in a select for update mode? > > No it is not dynamic. I don't think it should be. If it was you would have > to expose jboss internals to the application logic and that is not portable > across J2EE apps. > > > What I am looking for is simply the option to specify the wait option. > > May be a flag in jaws.xml to specify this on a per > > dbms type - > > in oracle its no wait - not sure what it is called in others. What do you > > think? > > > > What do you think of these ideas? What I wanted to do was extend the > database typemappings in standardjaws.xml. > > > > Oracle8 > true > ![CDATA[SELECT %i FROM %t WHERE %w FOR > UPDATE]] > true > ![CDATA[SELECT %i FROM %t WHERE %w FOR > UPDATE NOWAIT ]] > java.lang.Boolean > BIT > SMALLINT > > > where "%i" is the items to be select, "%t" is the tablename, and "%w" is the > where clause. If a bean turns on select-for-update and it is not supported > by the type-mapping, then an exception should be thrown on deployment. > Maybe your rowid thingy should be put in there as well in the same manner. > > And then in jaws.xml > > true > > Bill > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Running Multiple Instances of JBoss
Hello, Has anyone tried running multiple JBoss instances on a single machine? The last time I tried this it didn't work and was wondering if any changes have been made to allow multiple instances on a single machine? Thanks Vinay ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Select for update : Question for Bill
Hello Bill, Apologies for not following this up earlier than this but I was going to take a look at the no wait option for select for update operations. First of all is the select for update dynamic? i.e. can I start off in regular mode and then come back and load the same bean in a select for update mode? What I am looking for is simply the option to specify the wait option. May be a flag in jaws.xml to specify this on a per dbms type - in oracle its no wait - not sure what it is called in others. What do you think? Been a while since I've seen any JBoss code! Good to back though! Vinay ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] SELECT FOR UPDATE
depends on what the application set up. In our case we don't want the client to wait. If it encounters a lock throw an exception. Adding a should not be a problem but do we have a generic sql for that i.e.is it different in other dbms's? Also, do we want to have a global tag and a bean level tag? Vinay - Original Message - From: "Bill Burke" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, July 20, 2001 3:20 PM Subject: RE: [JBoss-dev] SELECT FOR UPDATE > I did the select for update. It would be easy to add NOT WAIT. I suggest > . It would be very easy to implement. Take a > look if you want to implement it yourself. > > I do disagree that most applications will want to throw an exception in case > of a lock not being acquired. For instance, we use select for update to > synch multiple instances of JBoss running on different machines. Plus, I > think select for update will timeout eventually with the transaction, won't > it? > > Bill > > > -Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Vinay > > Menon > > Sent: Friday, July 20, 2001 7:07 AM > > To: Dev @ JBoss > > Subject: [JBoss-dev] SELECT FOR UPDATE > > > > > > Hello, > > There is no option to do a SELECT .. FOR UPDATE ... NOT WAIT option in > > the current JAWS release. Most applications will just want to throw an > > exception in case a lock could not be acquired to let the user > > know that the > > record is being edited. And if you consider a case where you have client > > waiting for a lock to be released and some database problems occur that > > cause it to stall it could grow quite quickly with the number of clients > > waiting for a lock. As we planning for something of a NO WAIT > > option [as in > > Oracle] for this? > > > > Vinay > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] SELECT FOR UPDATE - NO WAIT
Hello, There is no option to do a SELECT .. FOR UPDATE ... NOT WAIT option in the current JAWS release. Most applications will just want to throw an exception in case a lock could not be acquired to let the user know that the record is being edited. And if you consider a case where you have client waiting for a lock to be released and some database problems occur that cause it to stall it could grow quite quickly with the number of clients waiting for a lock. As we planning for something of a NO WAIT option [as in Oracle] for this? Vinay ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] SELECT FOR UPDATE
Hello, There is no option to do a SELECT .. FOR UPDATE ... NOT WAIT option in the current JAWS release. Most applications will just want to throw an exception in case a lock could not be acquired to let the user know that the record is being edited. And if you consider a case where you have client waiting for a lock to be released and some database problems occur that cause it to stall it could grow quite quickly with the number of clients waiting for a lock. As we planning for something of a NO WAIT option [as in Oracle] for this? Vinay ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JAWS Rel_2_4_0_16 changes have been removed
can u pls let me know how i can get the test suite working from within the build scripts? the test script has a compileTest target which only builds the jmx bit. many thanks vinay - Original Message - From: "Scott M Stark" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, July 14, 2001 11:02 PM Subject: Re: [JBoss-dev] JAWS Rel_2_4_0_16 changes have been removed > These are the changes that were undone: > > [starksm@banshee-int jaws]$ cvs update -j Rel_2_4_0_16 -j Rel_2_4_0_15 > cvs server: Updating . > cvs server: Updating bmp > cvs server: Updating jdbc > RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCBeanExists Command.java,v > retrieving revision 1.7.6.1 > retrieving revision 1.7 > Merging differences between 1.7.6.1 and 1.7 into JDBCBeanExistsCommand.java > RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommand.ja va,v > retrieving revision 1.33.2.1 > retrieving revision 1.33 > Merging differences between 1.33.2.1 and 1.33 into JDBCCommand.java > RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCreateEnti tyCommand.java,v > retrieving revision 1.6.6.1 > retrieving revision 1.6 > Merging differences between 1.6.6.1 and 1.6 into JDBCCreateEntityCommand.java > RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCDefinedFin derCommand.java,v > retrieving revision 1.14.2.3 > retrieving revision 1.14.2.2 > Merging differences between 1.14.2.3 and 1.14.2.2 into JDBCDefinedFinderCommand.java > RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCFindByComm and.java,v > retrieving revision 1.10.2.1 > retrieving revision 1.10 > Merging differences between 1.10.2.1 and 1.10 into JDBCFindByCommand.java > RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCInitComman d.java,v > retrieving revision 1.12.6.2 > retrieving revision 1.12.6.1 > Merging differences between 1.12.6.2 and 1.12.6.1 into JDBCInitCommand.java > RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCLoadEntiti esCommand.java,v > retrieving revision 1.4.2.1 > retrieving revision 1.4 > Merging differences between 1.4.2.1 and 1.4 into JDBCLoadEntitiesCommand.java > RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCLoadEntity Command.java,v > retrieving revision 1.11.2.1 > retrieving revision 1.11 > Merging differences between 1.11.2.1 and 1.11 into JDBCLoadEntityCommand.java > RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCRemoveEnti tyCommand.java,v > retrieving revision 1.5.6.1 > retrieving revision 1.5 > Merging differences between 1.5.6.1 and 1.5 into JDBCRemoveEntityCommand.java > RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCStoreEntit yCommand.java,v > retrieving revision 1.7.6.1 > retrieving revision 1.7 > Merging differences between 1.7.6.1 and 1.7 into JDBCStoreEntityCommand.java > cvs server: Updating metadata > RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/JawsEntity MetaData.java,v > retrieving revision 1.9.4.2 > retrieving revision 1.9.4.1 > Merging differences between 1.9.4.2 and 1.9.4.1 into JawsEntityMetaData.java > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jaws_2_4.dtd not valid
Mike, That is a bean level datasource and quite obviously cannot be commented out in principal! I mean if you got to have a bean level ds you got to have one! Client programs should be able to define a datasource at the file level i.e. applicable to all the beans declared in the jaws.xml and the datasource at the bean level essentially overrides it. Vinay - Original Message - From: "Mike Swainston-Rainford" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, July 11, 2001 11:40 PM Subject: [JBoss-dev] jaws_2_4.dtd not valid > the jaws dtd is no longer valid. The datasource element is defined twice. > This mucks up any validating editor/parser (like XMLSpy) used to edit a > jaws.xml file. > > Suggest the second definition at line 69 is a comment thus:- > > > > > Mike S-R > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/metadata jaws_2_4.dtd
User: kvvinaymenon Date: 01/07/11 08:27:01 Modified:src/resources/org/jboss/metadata Tag: Branch_2_4 jaws_2_4.dtd Log: Support for stable row id based updates. Revision ChangesPath No revision No revision 1.1.2.3 +14 -2 jboss/src/resources/org/jboss/metadata/jaws_2_4.dtd Index: jaws_2_4.dtd === RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/metadata/jaws_2_4.dtd,v retrieving revision 1.1.2.2 retrieving revision 1.1.2.3 diff -u -r1.1.2.2 -r1.1.2.3 --- jaws_2_4.dtd 2001/07/03 20:50:21 1.1.2.2 +++ jaws_2_4.dtd 2001/07/11 15:27:01 1.1.2.3 @@ -28,7 +28,7 @@ - + @@ -59,7 +59,7 @@ time-out: For read-only only, re-load entity after time-out --> + table-name?,tuned-updates?,stable-rowid-column?,create-table?,remove-table?,select-for-update?,time-out?,pk-constraint?)> @@ -67,6 +67,18 @@ + + + + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ROWID: Final Call :)
Alright, Have checked in the code for rowid based update into Branch_2_4. Will probably wait for the changes to be validated before committing it to the HEAD as well. To use rowid based updates for Oracle a) In your bean class delcare a field 'rowid' of type String and declare it in your ejb-jar.xml and jaws.xml as you would with other CMP fields b) In your jaws.xml define an element rowid It should default to the primary key in case the row id is null - insert->update or insert->delete or combinations. You are all set to go! Please let me know if you face any issues with the code and I shall be more than happy to fix them. Regards, Vinay - Original Message ----- From: "Vinay Menon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, July 10, 2001 7:58 PM Subject: Re: [JBoss-dev] ROWID: Final Call :( > will do it if not today then tomorrow. > thanks! > vinay > - Original Message - > From: "marc fleury" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, July 10, 2001 3:27 PM > Subject: RE: [JBoss-dev] ROWID: Final Call :( > > > > vinay, > > > > chill, you have been here before. I recommendation to you is to commit > that > > code and document it HEAVILY so that people know it is there and how to > use > > it (if not fully automated) etc etc. > > > > It just doesn't work this way, nobody has time to review your code *as you > > post it*, so post it and if there is interest you will get the feedback > you > > need. It's nothing personal that's it. > > > > the rowid feature is very relevant and will bring tremendous CMP speed > > increases, so please go ahead, > > > > regards > > > > marcf > > |-Original Message- > > |From: [EMAIL PROTECTED] > > |[mailto:[EMAIL PROTECTED]]On Behalf Of Vinay > > |Menon > > |Sent: Tuesday, July 10, 2001 7:46 AM > > |To: Dev @ JBoss > > |Subject: [JBoss-dev] ROWID: Final Call :( > > | > > | > > |Hello guys, > > |Has anyone had the chance to take a look at the ROW ID thingey I had > > |posted [3 times!]. I have not heard back from anyone and think that if we > > |are NOT interested I should stop posting this question over and over > again. > > | > > |Vinay > > | > > | > > |___ > > |Jboss-development mailing list > > |[EMAIL PROTECTED] > > |http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/metadata JawsEntityMetaData.java
User: kvvinaymenon
Date: 01/07/11 08:03:26
Modified:src/main/org/jboss/ejb/plugins/jaws/metadata Tag: Branch_2_4
JawsEntityMetaData.java
Log:
Modified for support for stable row id based updates in databases like Oracle. The
jaws.xml file needs to include a field for the entity and its
value
should correspond to the name of the stable row id column e.g. rowid in Oracle.
Revision ChangesPath
No revision
No revision
1.9.4.2 +214 -206
jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/JawsEntityMetaData.java
Index: JawsEntityMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/JawsEntityMetaData.java,v
retrieving revision 1.9.4.1
retrieving revision 1.9.4.2
diff -u -r1.9.4.1 -r1.9.4.2
--- JawsEntityMetaData.java 2001/07/03 16:40:13 1.9.4.1
+++ JawsEntityMetaData.java 2001/07/11 15:03:26 1.9.4.2
@@ -36,58 +36,61 @@
* @author Sebastien Alborini
* @author mailto:[EMAIL PROTECTED]";>Dirk Zimmermann
* @author mailto:[EMAIL PROTECTED]";>Vinay Menon
- * @version $Revision: 1.9.4.1 $
+ * @version $Revision: 1.9.4.2 $
*/
public class JawsEntityMetaData extends MetaData implements XmlLoadable {
- // Constants -
+ // Constants -
- // Attributes
+ // Attributes
- // parent metadata structures
- private JawsApplicationMetaData jawsApplication;
- private EntityMetaData entity;
+ // parent metadata structures
+ private JawsApplicationMetaData jawsApplication;
+ private EntityMetaData entity;
- // the name of the bean (same as entity.getEjbName())
- private String ejbName = null;
+ // the name of the bean (same as entity.getEjbName())
+ private String ejbName = null;
- // the name of the table to use for this bean
- private String tableName = null;
+ // the name of the table to use for this bean
+ private String tableName = null;
- // do we have to try and create the table on deployment?
- private boolean createTable;
+ // do we have to try and create the table on deployment?
+ private boolean createTable;
- // do we have to drop the table on undeployment?
- private boolean removeTable;
+ // do we have to drop the table on undeployment?
+ private boolean removeTable;
- // do we use tuned updates?
- private boolean tunedUpdates;
+ // do we use tuned updates?
+ private boolean tunedUpdates;
+ //Enable fast updates based on stable row id column
+ private String stableRowIdColumn;
+
// do we use 'SELECT ... FOR UPDATE' syntax?
private boolean selectForUpdate;
- // is the bean read-only?
- private boolean readOnly;
- private int timeOut;
+ // is the bean read-only?
+ private boolean readOnly;
+ private int timeOut;
- // should the table have a primary key constraint?
- private boolean pkConstraint;
+ // should the table have a primary key constraint?
+ private boolean pkConstraint;
- // is the bean's primary key a composite object
- private boolean compositeKey;
+ // is the bean's primary key a composite object
+ private boolean compositeKey;
- // the class of the primary key
- private Class primaryKeyClass;
+ // the class of the primary key
+ private Class primaryKeyClass;
- // the fields we must persist for this bean
- private Hashtable cmpFields = new Hashtable();
+ // the fields we must persist for this bean
+ private Hashtable cmpFields = new Hashtable();
- // the fields that belong to the primary key (if composite)
- private ArrayList pkFields = new ArrayList();
+ // the fields that belong to the primary key (if composite)
+ private ArrayList pkFields = new ArrayList();
- // finders for this bean
- private ArrayList finders = new ArrayList();
+ // finders for this bean
+ private ArrayList finders = new ArrayList();
- // the bean level datasource
+ // the bean level datasource
/**
* This will now support datasources at the bean level. If no datasource
* has been specified at the bean level then the global datasource is used
@@ -96,104 +99,106 @@
* different datasources for different beans.
*
*/
- private DataSource dataSource=null;
+ private DataSource dataSource=null;
- /**
- * Here we store the basename of all detailed fields in j
Re: [JBoss-dev] [ jboss-Bugs-440167 ] null finder arg
Done. Will remember in future now that I have done this a couple of times :) Thanks - Original Message - From: "Scott M Stark" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, July 11, 2001 2:17 AM Subject: Re: [JBoss-dev] [ jboss-Bugs-440167 ] null finder arg > Tagging the main branch is good, but more importantly the release branch > needs to > be tagged and this was not done. You need to add a Rel_2_4_0_15 tag to the > entire jboss cvs module in your working directory that has the Branch_2_4 > checked out. > > - Original Message - > From: "Vinay Menon" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, July 10, 2001 4:12 PM > Subject: Re: [JBoss-dev] [ jboss-Bugs-440167 ] null finder arg > > > > This has now been patched in to Branch_2_4 and HEAD. The release has been > > incremented to Rel_2_5_0_3 [pls let me know if this is incorrect...]. > > > > Vinay > > - Original Message - > > From: <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Tuesday, July 10, 2001 8:24 PM > > Subject: [JBoss-dev] [ jboss-Bugs-440167 ] null finder arg > > > > > > > Bugs item #440167, was opened at 2001-07-10 12:24 > > > You can respond by visiting: > > > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-440167 ] null finder arg
This has now been patched in to Branch_2_4 and HEAD. The release has been incremented to Rel_2_5_0_3 [pls let me know if this is incorrect...]. Vinay - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, July 10, 2001 8:24 PM Subject: [JBoss-dev] [ jboss-Bugs-440167 ] null finder arg > Bugs item #440167, was opened at 2001-07-10 12:24 > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=376685&aid=440167&group_id= 22866 > > Category: JBossServer > Group: v2.2.2 (stable) > Status: Open > Resolution: None > Priority: 5 > Submitted By: Nobody/Anonymous (nobody) > Assigned to: Nobody/Anonymous (nobody) > Summary: null finder arg > > Initial Comment: > A declared cmp finder does not allow a null finder call argument. jboss gets the type of an > argument by calling getClass() on the instance. If the argument is null, this raises an exception > with the message "Find failed". > > jboss jaws plugin should check for a null argument and format the PreparedStatement accordingly. > To be precise, a null check on the arg in > org.jboss.ejb.plugins.jaws.jdbc.JDBCDefinedFinderCommand.setParameters(): > > if (arg == null) > jdbcType = java.sql.Types.NULL; > else > jdbcType = typeMapping.getJdbcTypeForJavaType(arg.getClass()); > > > -- > > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=376685&aid=440167&group_id= 22866 > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCDefinedFinderCommand.java
User: kvvinaymenon
Date: 01/07/10 16:04:37
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc Tag: Branch_2_4
JDBCDefinedFinderCommand.java
Log:
Fix for checking null arguments in Finders and ensuring that the NULL sql datatype
is assigned to such a variable. (Bugs item #440167)
Revision ChangesPath
No revision
No revision
1.14.2.2 +24 -15
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCDefinedFinderCommand.java
Index: JDBCDefinedFinderCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCDefinedFinderCommand.java,v
retrieving revision 1.14.2.1
retrieving revision 1.14.2.2
diff -u -r1.14.2.1 -r1.14.2.2
--- JDBCDefinedFinderCommand.java 2001/07/03 15:20:30 1.14.2.1
+++ JDBCDefinedFinderCommand.java 2001/07/10 23:04:37 1.14.2.2
@@ -28,7 +28,7 @@
* @author mailto:[EMAIL PROTECTED]";>Michel de Groot
* @author mailto:[EMAIL PROTECTED]";>Vinay Menon
* @author mailto:[EMAIL PROTECTED]";>danch (Dan Christopherson
- * @version $Revision: 1.14.2.1 $
+ * @version $Revision: 1.14.2.2 $
*/
public class JDBCDefinedFinderCommand extends JDBCFinderCommand
{
@@ -53,20 +53,20 @@
String query = "";
ArrayList parameters = new ArrayList();
if (f.getQuery() != null) {
- StringTokenizer finderQuery = new StringTokenizer(f.getQuery(),"{}",
true);
+ StringTokenizer finderQuery = new StringTokenizer(f.getQuery(),"{}", true);
- while (finderQuery.hasMoreTokens())
- {
- String t = finderQuery.nextToken();
- if (t.equals("{"))
- {
- query += "?";
- String idx = finderQuery.nextToken(); // Remove number
- parameters.add(new Integer(idx));
- finderQuery.nextToken(); // Remove }
- } else
- query += t;
- }
+ while (finderQuery.hasMoreTokens())
+ {
+String t = finderQuery.nextToken();
+if (t.equals("{"))
+{
+ query += "?";
+ String idx = finderQuery.nextToken(); // Remove number
+ parameters.add(new Integer(idx));
+ finderQuery.nextToken(); // Remove }
+} else
+ query += t;
+ }
}
// Copy index numbers to parameterArray
@@ -246,7 +246,16 @@
for (int i = 0; i < parameterArray.length; i++)
{
Object arg = args[parameterArray[i]];
- int jdbcType = typeMapping.getJdbcTypeForJavaType(arg.getClass());
+ int jdbcType;
+
+ if(arg!=null)
+ {
+ jdbcType = typeMapping.getJdbcTypeForJavaType(arg.getClass());
+ }
+ else
+ {
+ jdbcType = java.sql.Types.NULL;
+ }
setParameter(stmt,i+1,jdbcType,arg);
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCDefinedFinderCommand.java
User: kvvinaymenon
Date: 01/07/10 15:42:32
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc
JDBCDefinedFinderCommand.java
Log:
Fix for checking null arguments in Finders and ensuring that the NULL sql datatype
is assigned to such a variable. (Bugs item #440167)
Revision ChangesPath
1.17 +25 -15
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCDefinedFinderCommand.java
Index: JDBCDefinedFinderCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCDefinedFinderCommand.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- JDBCDefinedFinderCommand.java 2001/07/03 20:59:55 1.16
+++ JDBCDefinedFinderCommand.java 2001/07/10 22:42:32 1.17
@@ -29,7 +29,7 @@
* @author mailto:[EMAIL PROTECTED]";>Vinay Menon
* @author mailto:[EMAIL PROTECTED]";>danch (Dan Christopherson)
* @author mailto:[EMAIL PROTECTED]";>Bill Burke
- * @version $Revision: 1.16 $
+ * @version $Revision: 1.17 $
*
* Revisions:
* 20010621 Bill Burke: exposed parameterArray through get method.
@@ -57,20 +57,20 @@
String query = "";
ArrayList parameters = new ArrayList();
if (f.getQuery() != null) {
- StringTokenizer finderQuery = new StringTokenizer(f.getQuery(),"{}",
true);
+ StringTokenizer finderQuery = new StringTokenizer(f.getQuery(),"{}", true);
- while (finderQuery.hasMoreTokens())
- {
- String t = finderQuery.nextToken();
- if (t.equals("{"))
- {
- query += "?";
- String idx = finderQuery.nextToken(); // Remove number
- parameters.add(new Integer(idx));
- finderQuery.nextToken(); // Remove }
- } else
- query += t;
- }
+ while (finderQuery.hasMoreTokens())
+ {
+String t = finderQuery.nextToken();
+if (t.equals("{"))
+{
+ query += "?";
+ String idx = finderQuery.nextToken(); // Remove number
+ parameters.add(new Integer(idx));
+ finderQuery.nextToken(); // Remove }
+} else
+ query += t;
+ }
}
// Copy index numbers to parameterArray
@@ -255,7 +255,17 @@
for (int i = 0; i < parameterArray.length; i++)
{
Object arg = args[parameterArray[i]];
- int jdbcType = typeMapping.getJdbcTypeForJavaType(arg.getClass());
+ int jdbcType;
+
+ if(arg!=null)
+ {
+ jdbcType = typeMapping.getJdbcTypeForJavaType(arg.getClass());
+ }
+ else
+ {
+ jdbcType = java.sql.Types.NULL;
+ }
+
setParameter(stmt,i+1,jdbcType,arg);
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] IT'S ALIVE!!!!!
did we just bring down the site with all the traffic? - Original Message - From: "marc fleury" <[EMAIL PROTECTED]> To: "Jboss-User@Lists. Sourceforge. Net" <[EMAIL PROTECTED]>; "Jboss-Development@Lists. Sourceforge. Net" <[EMAIL PROTECTED]> Sent: Tuesday, July 10, 2001 7:07 PM Subject: [JBoss-dev] IT'S ALIVE! > > www.jboss.org/forums > > > so go and bang on it, might go down for some maintainance but let's see how > much fire we can bring on it. > > It is Jive/Jetty/JBoss > > you go girl! bring it on! > > marcf > > PS: jboss-user is dead! long live jboss-forums! > _ > Marc Fleury, Ph.D > [EMAIL PROTECTED] > _ > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ROWID: Final Call :(
will do it if not today then tomorrow. thanks! vinay - Original Message - From: "marc fleury" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, July 10, 2001 3:27 PM Subject: RE: [JBoss-dev] ROWID: Final Call :( > vinay, > > chill, you have been here before. I recommendation to you is to commit that > code and document it HEAVILY so that people know it is there and how to use > it (if not fully automated) etc etc. > > It just doesn't work this way, nobody has time to review your code *as you > post it*, so post it and if there is interest you will get the feedback you > need. It's nothing personal that's it. > > the rowid feature is very relevant and will bring tremendous CMP speed > increases, so please go ahead, > > regards > > marcf > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of Vinay > |Menon > |Sent: Tuesday, July 10, 2001 7:46 AM > |To: Dev @ JBoss > |Subject: [JBoss-dev] ROWID: Final Call :( > | > | > |Hello guys, > |Has anyone had the chance to take a look at the ROW ID thingey I had > |posted [3 times!]. I have not heard back from anyone and think that if we > |are NOT interested I should stop posting this question over and over again. > | > |Vinay > | > | > |___ > |Jboss-development mailing list > |[EMAIL PROTECTED] > |http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] ROWID: Final Call :(
Hello guys, Has anyone had the chance to take a look at the ROW ID thingey I had posted [3 times!]. I have not heard back from anyone and think that if we are NOT interested I should stop posting this question over and over again. Vinay ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-439861 ] JBOSS 2.4 problem
Can confirm that I use JBoss with both the thin and the OCI driver and have not had problems. - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 09, 2001 10:48 PM Subject: [JBoss-dev] [ jboss-Bugs-439861 ] JBOSS 2.4 problem > Bugs item #439861, was opened at 2001-07-09 14:48 > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=376685&aid=439861&group_id= 22866 > > Category: None > Group: None > Status: Open > Resolution: None > Priority: 5 > Submitted By: Nobody/Anonymous (nobody) > Assigned to: Nobody/Anonymous (nobody) > Summary: JBOSS 2.4 problem > > Initial Comment: > problem with JBOSS 2.4 Beta > I am using 2.4 Version. > But it doesn't support Oracle Thin driver > (oracle.jdbc.driver.OracleDriver). > Is it true or its fault in my coding?. > Actually same program works with JBOSS2 2.2, but fails > in 2.4 Beta.It gives error as No Suitable Driver for > the 'thin' which works fine in JBOSS 2.2. > > I am using NT 4.0 > JBOSS 2.4 beta > > > -- > > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=376685&aid=439861&group_id= 22866 > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jaws.dtd and jboss.dtd are frozen. They cannot be changed.
on second thoughts [and on truly and really waking up] do we just want the changes to jaws_2_4.dtd? - Original Message - From: "Scott M Stark" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 09, 2001 2:18 AM Subject: [JBoss-dev] jaws.dtd and jboss.dtd are frozen. They cannot be changed. > This change made to the jaws.dtd on the 2.4 branch and the similar change > made on main is invalid because the jaws.dtd and jboss.dtd files were frozen > to > what was supported by 2.2.x > > I am going to undo the change. Do not make any further changes to the > jboss.dtd > or jaws.dtd files. > > Revision 1.6.2.2 / (download) - annotate - [select for diffs] , Sun Jul 8 > 12:17:19 2001 UTC (12 hours, 45 minutes ago) by kvvinaymenon > Branch: Branch_2_4 > CVS Tags: Rel_2_4_0_13, Rel_2_4_0_12 > Changes since 1.6.2.1: +3 -1 lines > Diff to previous 1.6.2.1 to a branchpoint 1.6 > datasource change for allowing bean level datasources > > Revision 1.3 / (download) - annotate - [select for diffs] , Sun Jul 8 > 12:22:50 2001 UTC (12 hours, 47 minutes ago) by kvvinaymenon > Branch: MAIN > CVS Tags: HEAD > Changes since 1.2: +8 -3 lines > Diff to previous 1.2 > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jaws.dtd and jboss.dtd are frozen. They cannot be changed.
and so where do we want to see the datasource changes? - Original Message - From: "Scott M Stark" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 09, 2001 2:18 AM Subject: [JBoss-dev] jaws.dtd and jboss.dtd are frozen. They cannot be changed. > This change made to the jaws.dtd on the 2.4 branch and the similar change > made on main is invalid because the jaws.dtd and jboss.dtd files were frozen > to > what was supported by 2.2.x > > I am going to undo the change. Do not make any further changes to the > jboss.dtd > or jaws.dtd files. > > Revision 1.6.2.2 / (download) - annotate - [select for diffs] , Sun Jul 8 > 12:17:19 2001 UTC (12 hours, 45 minutes ago) by kvvinaymenon > Branch: Branch_2_4 > CVS Tags: Rel_2_4_0_13, Rel_2_4_0_12 > Changes since 1.6.2.1: +3 -1 lines > Diff to previous 1.6.2.1 to a branchpoint 1.6 > datasource change for allowing bean level datasources > > Revision 1.3 / (download) - annotate - [select for diffs] , Sun Jul 8 > 12:22:50 2001 UTC (12 hours, 47 minutes ago) by kvvinaymenon > Branch: MAIN > CVS Tags: HEAD > Changes since 1.2: +8 -3 lines > Diff to previous 1.2 > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JAWS_2_4 DTD
Agreed, Guess it is required! Anyway, have incremented the release version to 12 on the 2_4 branch. Hope its been done right! Vinay - Original Message - From: "Vincent Harcq" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, July 08, 2001 3:04 PM Subject: RE: [JBoss-dev] JAWS_2_4 DTD > The main trunk does not need any tags because we do not follow what is done > by revision on the main trunk. > On the main trunk you commit, commit and commit and don't take care of > revision: ALPHA. > Once a Branch is created, it means it is for a stable release, then we have > to be sure to know what has been done, so we use the release tags to fine > tune, be able to reproduce a problem by getting this specific release the > customer uses and on which he has the problem:BETA and FINAL. > When you use the main trunck, you are alone to find out any problems within > it. > It was unclear to me at the beginning, but it has in fact a lot of sense to > turn JBoss into a very fiable product. > Vincent. > > > -Message d'origine- > > De : [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]De la part de > > Vinay Menon > > Envoyé : dimanche 8 juillet 2001 14:33 > > À : [EMAIL PROTECTED] > > Objet : Re: [JBoss-dev] JAWS_2_4 DTD > > > > > > Vincent, > > Many thanks! I've commited the changes to the jaws.dtd and > > jaws_2_4.dtd > > to the main trunk as well [i.e the one without the Branch_2_4] tag. > > > > Now running cvs log at jboss24/ what I see is that Rel 2_4_0_11 > > was the last > > used tag and am going to increment it by one as you said and tag it. What > > about the trunk? > > > > Vinay > > > > - Original Message - > > From: "Vincent Harcq" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Sunday, July 08, 2001 1:14 PM > > Subject: RE: [JBoss-dev] JAWS_2_4 DTD > > > > > > > I am not sure Scott is around, so I'll try to explain. > > > > > > I check out "Branch_2_4" into a jboss24/ directory > > > I check out with no tags into jboss/ > > > > > > I change a file in jboss/, build, test and commit it > > > I copy the file in jboss24/, build, test and commit it > > > > > > I "cvs log" (from jboss/ for example) on "bin/run.sh" (for example), and > > see > > > the latest 2.4 Tag is Rel_2_4_0_11. > > > From "jboss24/" I then "cvs tag Rel_2_4_0_12" (recursively). > > > > > > Right? > > > > > > > -Message d'origine- > > > > De : [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED]]De la part de > > > > Vinay Menon > > > > Envoyé : dimanche 8 juillet 2001 13:48 > > > > À : [EMAIL PROTECTED] > > > > Objet : Re: [JBoss-dev] JAWS_2_4 DTD > > > > > > > > > > > > Scott, > > > > Alright did go thru the document. I am a complete CVS > > dumbo. Is this > > > > what I need to do > > > > > > > > 1. Check in all the changes back to Branch_2_4 AND to the main trunk? > > > > 2. Once I check in the code what is the 'cvs tag Rel_2_3_1_3' I should > > be > > > > using? > > > > > > > > Many thanks in advance. > > > > > > > > Vinay > > > > > > > > > > > > - Original Message - > > > > From: "Scott M Stark" <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]> > > > > Sent: Sunday, July 08, 2001 12:15 AM > > > > Subject: Re: [JBoss-dev] JAWS_2_4 DTD > > > > > > > > > > > > > kvvinaymenon, > > > > > > > > > > You need to follow the cvs proceedures for updating a branch and > > making > > > > sure > > > > > the changes are applied to main. Read them here: > > > > > http://www.jboss.org/CVSAdmin.jsp > > > > > and then clean up your changes. > > > > > > > > > > - Original Message - > > > > > From: "Mike Swainston-Rainford" <[EMAIL PROTECTED]> > > > > > To: <[EMAIL PROTECTED]> > > > > > Sent: Saturday, July 07, 2001 3:56 PM > > > > > Subject: [JBoss-dev] JAWS_2_4 DTD > > > > > > > > > > > > > > > > > > > > > > the datasource element was added to the entity element in v
Re: [JBoss-dev] JAWS_2_4 DTD
Isn't is a slight misnomer then if we have things like jaws_2_4.dtd in the main trunk? - Original Message - From: "marc fleury" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, July 08, 2001 1:33 PM Subject: RE: [JBoss-dev] JAWS_2_4 DTD > oka > > marcf > > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott > |M Stark > |Sent: Sunday, July 08, 2001 2:04 AM > |To: [EMAIL PROTECTED] > |Subject: Re: [JBoss-dev] JAWS_2_4 DTD > | > | > |We decided to forgo an explicit future 3.0 branch and just make main > |the place for future development. Commit the rabbit hole work to main > |and it becomes a part of the current 2.5 development work. It will be > |released as a 3.0 branch. > | > |- Original Message - > |From: "marc fleury" <[EMAIL PROTECTED]> > |To: <[EMAIL PROTECTED]> > |Sent: Saturday, July 07, 2001 9:07 PM > |Subject: RE: [JBoss-dev] JAWS_2_4 DTD > | > | > |> ok good, so I need to deal with the branch stuff only if I want to back > |port > |> something. Ok. > |> > |> what happened to the 3.0 branch? I am finishing the jive stuff online > |> (moving the forums) and would like to commit the rabbit hole work I > |> have... will that go in 2.5? > |> > |> it is really "new" work... new Main, new configuration, the full j2ee > |> shebang flirting with web services... will that go 2.5 if I don't cvs > |> something? > |> > |> I am still a *little bit* confused :)) > |> > |> he he, I feel like a monkey, > |> > |> TIA and all that > |> > |> marcf > |> > |> |-Original Message- > |> |From: [EMAIL PROTECTED] > |> |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott > |> |M Stark > |> |Sent: Saturday, July 07, 2001 11:49 PM > |> |To: [EMAIL PROTECTED] > |> |Subject: Re: [JBoss-dev] JAWS_2_4 DTD > |> | > |> | > |> |Right, you committed to main. This is the 2.5 effort although its not a > |> |branch. > |> | > |> |- Original Message - > |> |From: "marc fleury" <[EMAIL PROTECTED]> > |> |To: <[EMAIL PROTECTED]> > |> |Sent: Saturday, July 07, 2001 6:34 PM > |> |Subject: RE: [JBoss-dev] JAWS_2_4 DTD > |> | > |> | > |> |> ok, > |> |> I am super confused... > |> |> > |> |> so the changes I made to the interceptor won't show in 2.4 right? only > |in > |> |> the 2.5 branch. > |> |> > |> |> marcf > |> |> > |> |> |-Original Message- > |> |> |From: [EMAIL PROTECTED] > |> |> |[mailto:[EMAIL PROTECTED]]On Behalf Of > |Scott > |> |> |M Stark > |> |> |Sent: Saturday, July 07, 2001 7:33 PM > |> |> |To: [EMAIL PROTECTED] > |> |> |Subject: Re: [JBoss-dev] JAWS_2_4 DTD > |> |> | > |> |> | > |> |> |Yes, every incremental change made on a branch needs to be tagged to > |> |> |make it easy to identify the changes going into a release. > |> |> | > |> |> |- Original Message - > |> |> |From: "Aaron Mulder" <[EMAIL PROTECTED]> > |> |> |To: <[EMAIL PROTECTED]> > |> |> |Sent: Saturday, July 07, 2001 4:18 PM > |> |> |Subject: Re: [JBoss-dev] JAWS_2_4 DTD > |> |> | > |> |> | > |> |> |> On Sat, 7 Jul 2001, Scott M Stark wrote: > |> |> |> > When you make a change to a branch you need to tag it with the > |> |> |> > next beta binary release tag: > |> |Rel_... > |> |> |> > |> |> |> Are you saying that a release does not just label and use the > |> |> |> "head of the branch" but is built based on a label created at the > |time > |> |of > |> |> |> the previous release or something? Wouldn't it just be easier to > |tag > |> |the > |> |> |> current code in the branch when you're ready to make the release? > |> |> |> I made a change to the 2.4 metadata to handle the array types > |> |> |> (which never showed up on the mailing list due to the CVS > |> |> |weirdness but is > |> |> |> actually in the repository). I did not actually tag it > |> |though, so if I > |> |> |> need to tag it in order for it to be included in the next > |> |build, let me > |> |> |> know. > |> |> |> > |> |> |> Aaron > |> |> |> > |> |> | > |> |> | > |> |> | > |> |> |___ > |> |> |Jboss-development mailing list > |> |> |[EMAIL PROTECTED] > |> |> |http://lists.sourceforge.net/lists/listinfo/jboss-development > |> |> > |> |> > |> |> > |> |> ___ > |> |> Jboss-development mailing list > |> |> [EMAIL PROTECTED] > |> |> http://lists.sourceforge.net/lists/listinfo/jboss-development > |> |> > |> | > |> | > |> |___ > |> |Jboss-development mailing list > |> |[EMAIL PROTECTED] > |> |http://lists.sourceforge.net/lists/listinfo/jboss-development > |> > |> > |> > |> ___ > |> Jboss-development mailing list > |> [EMAIL PROTECTED] > |> http://lists.sourceforge.net/lists/listinfo/jboss-development > |> > | > | > |___ > |Jboss-development mailing list > |[EMAIL PROTECTED] > |http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ___
Re: [JBoss-dev] JAWS_2_4 DTD
Vincent, Many thanks! I've commited the changes to the jaws.dtd and jaws_2_4.dtd to the main trunk as well [i.e the one without the Branch_2_4] tag. Now running cvs log at jboss24/ what I see is that Rel 2_4_0_11 was the last used tag and am going to increment it by one as you said and tag it. What about the trunk? Vinay - Original Message - From: "Vincent Harcq" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, July 08, 2001 1:14 PM Subject: RE: [JBoss-dev] JAWS_2_4 DTD > I am not sure Scott is around, so I'll try to explain. > > I check out "Branch_2_4" into a jboss24/ directory > I check out with no tags into jboss/ > > I change a file in jboss/, build, test and commit it > I copy the file in jboss24/, build, test and commit it > > I "cvs log" (from jboss/ for example) on "bin/run.sh" (for example), and see > the latest 2.4 Tag is Rel_2_4_0_11. > From "jboss24/" I then "cvs tag Rel_2_4_0_12" (recursively). > > Right? > > > -Message d'origine- > > De : [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]De la part de > > Vinay Menon > > Envoyé : dimanche 8 juillet 2001 13:48 > > À : [EMAIL PROTECTED] > > Objet : Re: [JBoss-dev] JAWS_2_4 DTD > > > > > > Scott, > > Alright did go thru the document. I am a complete CVS dumbo. Is this > > what I need to do > > > > 1. Check in all the changes back to Branch_2_4 AND to the main trunk? > > 2. Once I check in the code what is the 'cvs tag Rel_2_3_1_3' I should be > > using? > > > > Many thanks in advance. > > > > Vinay > > > > > > - Original Message - > > From: "Scott M Stark" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Sunday, July 08, 2001 12:15 AM > > Subject: Re: [JBoss-dev] JAWS_2_4 DTD > > > > > > > kvvinaymenon, > > > > > > You need to follow the cvs proceedures for updating a branch and making > > sure > > > the changes are applied to main. Read them here: > > > http://www.jboss.org/CVSAdmin.jsp > > > and then clean up your changes. > > > > > > - Original Message - > > > From: "Mike Swainston-Rainford" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Saturday, July 07, 2001 3:56 PM > > > Subject: [JBoss-dev] JAWS_2_4 DTD > > > > > > > > > > > > > > the datasource element was added to the entity element in version > > 1.1.2.2 > > > > on Bracnh_2_4. But it hasn't been updated on the main branch > > or added to > > > > the 2_4 label. Shouldn't this change go onto both main and the current > > 2_4 > > > > label? > > > > > > > > There is also a code change associated with this - > > > > src/main/org/jboss/ejb/plugins/jaws/metadata/JawsEntityMetaData.java > > also > > > > on the 2_4 branch but not in the label but these changes are on main > > > (added > > > > in version 1.11). > > > > > > > > Mike S-R > > > > > > > > > > > > ___ > > > > Jboss-development mailing list > > > > [EMAIL PROTECTED] > > > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/metadata jaws.dtd jaws_2_4.dtd
User: kvvinaymenon Date: 01/07/08 05:22:50 Modified:src/resources/org/jboss/metadata jaws.dtd jaws_2_4.dtd Log: datasource change for allowing bean level datasources.Checking in dtd file changes to the main trunk. Revision ChangesPath 1.11 +3 -4 jboss/src/resources/org/jboss/metadata/jaws.dtd Index: jaws.dtd === RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/metadata/jaws.dtd,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- jaws.dtd 2001/07/05 19:02:22 1.10 +++ jaws.dtd 2001/07/08 12:22:50 1.11 @@ -1,8 +1,5 @@ @@ -13,9 +10,11 @@ - + + + 1.3 +8 -3 jboss/src/resources/org/jboss/metadata/jaws_2_4.dtd Index: jaws_2_4.dtd === RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/metadata/jaws_2_4.dtd,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- jaws_2_4.dtd 2001/06/22 21:19:05 1.2 +++ jaws_2_4.dtd 2001/07/08 12:22:50 1.3 @@ -14,7 +14,10 @@ + context. The default is java:/DefaultDS + + Beans are also allowed to specify datasources at bean level and will override this datasource if specified. + --> - - + + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/metadata jaws.dtd
User: kvvinaymenon Date: 01/07/08 05:17:19 Modified:src/resources/org/jboss/metadata Tag: Branch_2_4 jaws.dtd Log: datasource change for allowing bean level datasources Revision ChangesPath No revision No revision 1.6.2.2 +3 -1 jboss/src/resources/org/jboss/metadata/jaws.dtd Index: jaws.dtd === RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/metadata/jaws.dtd,v retrieving revision 1.6.2.1 retrieving revision 1.6.2.2 diff -u -r1.6.2.1 -r1.6.2.2 --- jaws.dtd 2001/06/22 21:19:50 1.6.2.1 +++ jaws.dtd 2001/07/08 12:17:19 1.6.2.2 @@ -10,9 +10,11 @@ - + + + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JAWS_2_4 DTD
Scott, Alright did go thru the document. I am a complete CVS dumbo. Is this what I need to do 1. Check in all the changes back to Branch_2_4 AND to the main trunk? 2. Once I check in the code what is the 'cvs tag Rel_2_3_1_3' I should be using? Many thanks in advance. Vinay - Original Message - From: "Scott M Stark" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, July 08, 2001 12:15 AM Subject: Re: [JBoss-dev] JAWS_2_4 DTD > kvvinaymenon, > > You need to follow the cvs proceedures for updating a branch and making sure > the changes are applied to main. Read them here: > http://www.jboss.org/CVSAdmin.jsp > and then clean up your changes. > > - Original Message - > From: "Mike Swainston-Rainford" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, July 07, 2001 3:56 PM > Subject: [JBoss-dev] JAWS_2_4 DTD > > > > > > the datasource element was added to the entity element in version 1.1.2.2 > > on Bracnh_2_4. But it hasn't been updated on the main branch or added to > > the 2_4 label. Shouldn't this change go onto both main and the current 2_4 > > label? > > > > There is also a code change associated with this - > > src/main/org/jboss/ejb/plugins/jaws/metadata/JawsEntityMetaData.java also > > on the 2_4 branch but not in the label but these changes are on main > (added > > in version 1.11). > > > > Mike S-R > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JAWS_2_4 DTD
Will clean it up today ... once I get around the CVS policy documentation .. it is a pretty complex beast! - Original Message - From: "Scott M Stark" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, July 08, 2001 12:15 AM Subject: Re: [JBoss-dev] JAWS_2_4 DTD > kvvinaymenon, > > You need to follow the cvs proceedures for updating a branch and making sure > the changes are applied to main. Read them here: > http://www.jboss.org/CVSAdmin.jsp > and then clean up your changes. > > - Original Message - > From: "Mike Swainston-Rainford" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, July 07, 2001 3:56 PM > Subject: [JBoss-dev] JAWS_2_4 DTD > > > > > > the datasource element was added to the entity element in version 1.1.2.2 > > on Bracnh_2_4. But it hasn't been updated on the main branch or added to > > the 2_4 label. Shouldn't this change go onto both main and the current 2_4 > > label? > > > > There is also a code change associated with this - > > src/main/org/jboss/ejb/plugins/jaws/metadata/JawsEntityMetaData.java also > > on the 2_4 branch but not in the label but these changes are on main > (added > > in version 1.11). > > > > Mike S-R > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Is the JBoss website down for maintenance?
___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Tomcat/JMS Classes not found
Guess as long as it is intended and more importantly 'documented' somewhere users are not going to get surprised! Vinay - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: "Dev @ JBoss" <[EMAIL PROTECTED]> Sent: Wednesday, July 04, 2001 12:03 AM Subject: Re: [JBoss-dev] Tomcat/JMS Classes not found > > [Configuration] org.jboss.configuration.ConfigurationException: missing > > required > > attribute: QueueFactoryRef when I start up the server. > > > > The MDB support is assuming that both QueueFactoryRef and TopicFactoryRef > are non-null. I added this to make it clear what the problem is instead of > the MDB sub-system throwing non-helpful NullPointerExceptions. > > --jason > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS Query: Where to check in?
With the branch and the head in CVS where do we commit to? I commited JawsEntityMetaData.java to both Branch_2_4 and the main trunk. Is this what we want? Or do I just commit to the branch which later gets merged to the trunk. Also, the fix for the finder in JDBCDefinedFinderCommand.java has been commited only to branch... will wait till I hear from someone! Cheers Vinay ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Tomcat/JMS Classes not found
Am I missing something or has org.jboss.tomcat.EmbeddedTomcatServiceSX gone? The jboss.conf file still seems to have a reference to it .. Am also getting [Configuration] org.jboss.configuration.ConfigurationException: missing required attribute: QueueFactoryRef when I start up the server. Not finding org.jboss.tomcat.security.JBossSecurityMgrRealm And here is the rest [Default] At Line 187 /Server/ContextManager/RequestInterceptor/ className=org.j boss.tomcat.security.JBossSecurityMgrRealm [Default] [Default] FATAL: configuration error [Default] java.lang.ClassNotFoundException: org.jboss.tomcat.security.JBossSecurityMgrRealm [Default] at javax.management.loading.MLet.findClass(MLet.java:800) [Default] [Default] at java.lang.ClassLoader.loadClass(Unknown Source) [Default] [Default] at java.lang.ClassLoader.loadClass(Unknown Source) [Default] [Default] at java.lang.ClassLoader.loadClassInternal(Unknown Source) [Default] [Default] at java.lang.Class.forName0(Native Method) [Default] [Default] at java.lang.Class.forName(Unknown Source) [Default] [Default] at org.apache.tomcat.util.xml.ObjectCreate.start(XmlMapper.java: 580) [Default] [Default] at org.apache.tomcat.util.xml.XmlMapper.matchStart(XmlMapper.jav a:384) [Default] [Default] at org.apache.tomcat.util.xml.XmlMapper.startElement(XmlMapper.j ava:81) [Default] [Default] at org.xml.sax.helpers.XMLReaderAdapter.startElement(XMLReaderAd apter.java:329) [Default] [Default] at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1 451) [Default] [Default] at org.apache.crimson.parser.Parser2.content(Parser2.java:1700) [Default] [Default] at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1 468) [Default] [Default] at org.apache.crimson.parser.Parser2.content(Parser2.java:1700) [Default] [Default] at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1 468) [Default] [Default] at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java: 499) [Default] [Default] at org.apache.crimson.parser.Parser2.parse(Parser2.java:304) [Default] [Default] at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.j ava:433) [Default] [Default] at org.xml.sax.helpers.XMLReaderAdapter.parse(XMLReaderAdapter.j ava:223) [Default] [Default] at javax.xml.parsers.SAXParser.parse(SAXParser.java:317) [Default] [Default] at javax.xml.parsers.SAXParser.parse(SAXParser.java:260) [Default] [Default] at org.apache.tomcat.util.xml.XmlMapper.readXml(XmlMapper.java:2 14) [Default] [Default] at org.jboss.tomcat.TomcatEntry.execute(TomcatEntry.java:317) [Default] [Default] at org.jboss.tomcat.TomcatEntry.(TomcatEntry.java:72) [Default] [Default] at org.jboss.tomcat.EmbeddedTomcatService.startService(EmbeddedT omcatService.java:69) [Default] [Default] at org.jboss.util.ServiceMBeanSupport.start(ServiceMBeanSupport. java:109) [Default] [Default] at java.lang.reflect.Method.invoke(Native Method) [Default] [Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl .java:1628) [Default] [Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl .java:1523) [Default] [Default] at org.jboss.configuration.ConfigurationService$ServiceProxy.inv oke(ConfigurationService.java:938) [Default] [Default] at $Proxy0.start(Unknown Source) [Default] [Default] at org.jboss.util.ServiceControl.start(ServiceControl.java:83) [Default] [Default] at java.lang.reflect.Method.invoke(Native Method) [Default] [Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl .java:1628) [Default] [Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl .java:1523) [Default] [Default] at org.jboss.Main.(Main.java:209) [Default] [Default] at org.jboss.Main$1.run(Main.java:115) [Default] [Default] at java.security.AccessController.doPrivileged(Native Method) [Default] [Default] at org.jboss.Main.main(Main.java:111) [Default] [Default] Starting tomcat. Check logs/tomcat.log for error messages [Default] 2001-07-03 05:10:09 - ContextManager: Adding context Ctx( /admin ) [Default] 2001-07-03 05:10:09 - ContextManager: Adding context Ctx( /ebillclient ) [Default] 2001-07-03 05:10:09 - ContextManager: Adding context Ctx( /ebilling ) [Default] 2001-07-03 05:10:09 - ContextManager: Adding context Ctx( /examples ) [Default] 2001-07-03 05:10:09 - ContextManager: Adding context Ctx( ) [Default] 2001-07-03 05:10:09 - ContextManager: Adding context Ctx( /test ) [Default] Binding ejb/Invoice to ejb/Invoice [Default] Binding jdbc/ukdb to java:/ukdb [Default] Binding jdbc/ebilldb to java:/ebill [Default] Binding jdbc/edb to java:/edb [EmbeddedTomcatService] OK [EmbeddedTomcatService] Started [JBossMQService] Starting [Default] Server Version 0.8 Started [JBossMQService] Started [JMSProviderLoader] Starting
Re: [JBoss-dev] [ jboss-Bugs-438115 ] JAWS lower-cases custom finder SQL text
Jay,
Obviously, that is why I said that converting the finder query to lower
case is not correct.
Here is the changed code in JDBCFinderCommand.
if (lcQuery.startsWith(",") || lcQuery.startsWith("inner join")) {
//this is the case of a 'where' that is build to actually join
tables:
// ,table2 as foo where foo.col1 = entitytable.col2 AND
entitytable.filter = {1}
// or
// inner join table2 on table2.col1 = entitytable.col2 AND
entitytable.filter = {1}
String tableList = null;
int whereStart = lcQuery.indexOf("where");
if (whereStart == -1) {
//log this at debug in case someone has made a mistake, but
assume that
// they mean a findAll.
log.debug("Strange query for finder "+f.getName()+
". Includes join, but no 'where' clause. Is this a
findAll?");
tableList = query;
whereClause = "";
} else {
tableList = query.substring(0, whereStart);
whereClause = query.substring(whereStart);
}
fromClause = "FROM "+jawsEntity.getTableName()+tableList;
} else {
fromClause = "FROM "+jawsEntity.getTableName();
if (lcQuery.startsWith("where"))
whereClause = query;
else
whereClause = "where "+query;
}
Vinay
- Original Message -
From: "Jay Walters" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 03, 2001 2:03 PM
Subject: RE: [JBoss-dev] [ jboss-Bugs-438115 ] JAWS lower-cases custom
finder SQL text
> They are all case sensitive when it comes to the data...
>
> -Original Message-
> From: Vinay Menon [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 03, 2001 8:59 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] [ jboss-Bugs-438115 ] JAWS lower-cases custom
> finder SQL text
>
>
> Dan,
> Oracle case sensitive as well. One of the chaps here put a finder
query
> ... "where flg='T'"
>
> Obviously it didn't work cos the JDBCDefinedFinderCommand issued it to
> the backed as "where flg=i't'". This is cos the where clause is
constructed
> with the lower case query. Do you want me to fix it?
>
> Vinay
>
> - Original Message -
> From: "danch" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, July 03, 2001 4:17 AM
> Subject: Re: [JBoss-dev] [ jboss-Bugs-438115 ] JAWS lower-cases custom
> finder SQL text
>
>
> > Does anybody know what databases are case sensitive WRT column and table
> > names (or even keywords). I've never run into case sensitive SQL
> > databases before.
> >
> > [EMAIL PROTECTED] wrote:
> >
> > > Bugs item #438115, was opened at 2001-07-02 19:50
> > > You can respond by visiting:
> > >
>
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=438115&group_id=
> 22866
> > >
> > > Category: JBossCMP
> > > Group: v2.4 BETA (stable)
> > > Status: Open
> > > Resolution: None
> > > Priority: 5
> > > Submitted By: Michael Jara (mjara)
> > > Assigned to: Nobody/Anonymous (nobody)
> > > Summary: JAWS lower-cases custom finder SQL text
> > >
> > > Initial Comment:
> > > JAWS is now lower-casing all custom finder SQL text
> > > specified in jaws.xml. Most database drivers seem to
> > > ignore case, but some (such as JConnect5.2/SybaseASE)
> > > do not.
> > >
> > > For example, if I have this in my jaws.xml file:
> > >
> > >
> > > EventDescription
> > >
> > > findByEventType
> > > , TypeDescriptionPair,
> > > EventType WHERE EventType.description={0} AND
> > > EventType.enumerationIndex=TypeDescriptionPair.eventTyp
> > > eKey AND
> > > TypeDescriptionPair.eventDescriptionKey=EventDescriptio
> > > n.enumerationIndex
> > >
> > > EventDescription.description
> > >
> > >
> > >
> > > All table and field names are lower-cased on
> > > execution. This is the trace logged in Beta 2.4:
> > >
> > > 2001-07-02 20:39:22,195 [RMI TCP Connection(8)-
> > > 161.218.184.161] DEBUG JAWS - findByEventType command
> > > executing: SELECT EventDescription.enumerationIndex,
> > > EventDescription.description FROM EventDescription,
> > > typedescriptionpair, eventtype where
> > > even
Re: [JBoss-dev] [ jboss-Bugs-438115 ] JAWS lower-cases custom finder SQL text
Dan,
Oracle case sensitive as well. One of the chaps here put a finder query
... "where flg='T'"
Obviously it didn't work cos the JDBCDefinedFinderCommand issued it to
the backed as "where flg=i't'". This is cos the where clause is constructed
with the lower case query. Do you want me to fix it?
Vinay
- Original Message -
From: "danch" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 03, 2001 4:17 AM
Subject: Re: [JBoss-dev] [ jboss-Bugs-438115 ] JAWS lower-cases custom
finder SQL text
> Does anybody know what databases are case sensitive WRT column and table
> names (or even keywords). I've never run into case sensitive SQL
> databases before.
>
> [EMAIL PROTECTED] wrote:
>
> > Bugs item #438115, was opened at 2001-07-02 19:50
> > You can respond by visiting:
> >
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=438115&group_id=
22866
> >
> > Category: JBossCMP
> > Group: v2.4 BETA (stable)
> > Status: Open
> > Resolution: None
> > Priority: 5
> > Submitted By: Michael Jara (mjara)
> > Assigned to: Nobody/Anonymous (nobody)
> > Summary: JAWS lower-cases custom finder SQL text
> >
> > Initial Comment:
> > JAWS is now lower-casing all custom finder SQL text
> > specified in jaws.xml. Most database drivers seem to
> > ignore case, but some (such as JConnect5.2/SybaseASE)
> > do not.
> >
> > For example, if I have this in my jaws.xml file:
> >
> >
> > EventDescription
> >
> > findByEventType
> > , TypeDescriptionPair,
> > EventType WHERE EventType.description={0} AND
> > EventType.enumerationIndex=TypeDescriptionPair.eventTyp
> > eKey AND
> > TypeDescriptionPair.eventDescriptionKey=EventDescriptio
> > n.enumerationIndex
> >
> > EventDescription.description
> >
> >
> >
> > All table and field names are lower-cased on
> > execution. This is the trace logged in Beta 2.4:
> >
> > 2001-07-02 20:39:22,195 [RMI TCP Connection(8)-
> > 161.218.184.161] DEBUG JAWS - findByEventType command
> > executing: SELECT EventDescription.enumerationIndex,
> > EventDescription.description FROM EventDescription,
> > typedescriptionpair, eventtype where
> > eventtype.description=? and
> > eventtype.enumerationindex=typedescriptionpair.eventtyp
> > ekey and
> > typedescriptionpair.eventdescriptionkey=eventdescriptio
> > n.enumerationindex ORDER BY
> > EventDescription.description
> > 2001-07-02 20:39:22,195 [RMI TCP Connection(8)-
> > 161.218.184.161] DEBUG JAWS - Set parameter: idx=1,
> > jdbcType=VARCHAR, value=Construction
> > 2001-07-02 20:39:22,285 [RMI TCP Connection(8)-
> > 161.218.184.161] DEBUG JAWS -
> > com.sybase.jdbc2.jdbc.SybSQLException: The column
> > prefix 'eventdescription' does not match with a table
> > name or alias name used in the query. Either the table
> > is not specified in the FROM clause or it has a
> > correlation name which must be used instead.
> >
> > This DOES work properly in release 2.2 (maintaining
> > case as entered in jaws.xml.)
> >
> > --
> >
> > You can respond by visiting:
> >
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=438115&group_id=
22866
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] EJB 2.0 Locking for CMR
Hello, After reading the CMP section in the ejb spec pfd2 I still am not sure about the way locking mechanisms will work in ejb2.0? How is it being implemented in JBoss? If I have a table A and it has a one-to-many relationship with table B [entities in B have a foreign key relationship with A]. Now if I do a select for update for an entity in table B a) will it prevent other clients from doing deletes of the associated entity in A? The spec says that when you do a remove from A it will remove all assoicated entities and then remove the entity itself [10.3.4.1] but what about the other way round? b) Will it prevent primary key update of the associated entity in A? Spec 10.3.5 says NO. But if so how will locking work especially in a one to many relationship where other entities might end up in contention for the same parent entity? I am probably just being silly but have we got an idea as to how this is going to be implemented? Vinay ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ClassCastException in jBoss TE in VAJ 3.5
Hmm,
Should you be specifying port 1099 as part of the url?
Vinay
- Original Message -
From: "Kristoffer Larsson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 02, 2001 3:13 PM
Subject: Re: [JBoss-dev] ClassCastException in jBoss TE in VAJ 3.5
> On Mon, 2 Jul 2001, Vinay Menon wrote:
>
> > your client needs jars under JBOSS_HOME/client .
>
> It already has them in its classpath. However, when it didn't I got
> NoClassDefFoundError, not ClassCastException.
>
> / Kristoffer
>
> >
> > - Original Message -
> > From: "Kristoffer Larsson" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, July 02, 2001 2:16 PM
> > Subject: [JBoss-dev] ClassCastException in jBoss TE in VAJ 3.5
> >
> >
> > >
> > > I am running VisualAge for Java 3.5 and the jBoss Test Environment
> > > and have written a simple client to the example EJB
> > > org.jboss.test.tomcat.ejb.bean.jBoss.StatelessSessionBean. However,
> > > when I try to run the client I get this nasty exception:
> > >
> > > javax.naming.NoInitialContextException: Cannot instantiate class:
> > > org.jnp.interfaces.NamingContextFactory. Root exception is
> > > java.lang.ClassCastException
> > > java.lang.Throwable()
> > > java.lang.Exception()
> > > java.lang.RuntimeException()
> > > java.lang.ClassCastException()
> > > javax.naming.Context
> > > javax.naming.spi.NamingManager.getInitialContext(java.util.Hashtable)
> > > javax.naming.Context
> > > javax.naming.spi.NamingManager.getInitialContext(java.util.Hashtable)
> > > javax.naming.Context
> > > javax.naming.InitialContext.getDefaultInitCtx()
> > > void javax.naming.InitialContext.init(java.util.Hashtable)
> > > javax.naming.InitialContext(java.util.Hashtable)
> > > void Test.TestJBoss.main(java.lang.String [])
> > >
> > >
> > > My client begins like this:
> > >
> > >
> > > import javax.naming.InitialContext;
> > > import javax.rmi.PortableRemoteObject;
> > >
> > > import org.jboss.test.tomcat.ejb.interfaces.StatelessSession;
> > > import org.jboss.test.tomcat.ejb.interfaces.StatelessSessionHome;
> > >
> > > public class TestJBoss {
> > >
> > > public static void main(String[] args) {
> > >
> > > try
> > > {
> > > java.util.Hashtable properties = new java.util.Hashtable(3);
> > > properties.put(javax.naming.Context.PROVIDER_URL, "localhost");
> > > properties.put(javax.naming.Context.URL_PKG_PREFIXES,
> > "org.jboss.naming");
> > > properties.put(javax.naming.Context.INITIAL_CONTEXT_FACTORY,
> > >"org.jnp.interfaces.NamingContextFactory");
> > > InitialContext context = new InitialContext(properties);
> > >
> > > [...]
> > >
> > >
> > > Why the exception? Any help appreciated ...
> > >
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ClassCastException in jBoss TE in VAJ 3.5
your client needs jars under JBOSS_HOME/client .
- Original Message -
From: "Kristoffer Larsson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 02, 2001 2:16 PM
Subject: [JBoss-dev] ClassCastException in jBoss TE in VAJ 3.5
>
> I am running VisualAge for Java 3.5 and the jBoss Test Environment
> and have written a simple client to the example EJB
> org.jboss.test.tomcat.ejb.bean.jBoss.StatelessSessionBean. However,
> when I try to run the client I get this nasty exception:
>
> javax.naming.NoInitialContextException: Cannot instantiate class:
> org.jnp.interfaces.NamingContextFactory. Root exception is
> java.lang.ClassCastException
> java.lang.Throwable()
> java.lang.Exception()
> java.lang.RuntimeException()
> java.lang.ClassCastException()
> javax.naming.Context
> javax.naming.spi.NamingManager.getInitialContext(java.util.Hashtable)
> javax.naming.Context
> javax.naming.spi.NamingManager.getInitialContext(java.util.Hashtable)
> javax.naming.Context
> javax.naming.InitialContext.getDefaultInitCtx()
> void javax.naming.InitialContext.init(java.util.Hashtable)
> javax.naming.InitialContext(java.util.Hashtable)
> void Test.TestJBoss.main(java.lang.String [])
>
>
> My client begins like this:
>
>
> import javax.naming.InitialContext;
> import javax.rmi.PortableRemoteObject;
>
> import org.jboss.test.tomcat.ejb.interfaces.StatelessSession;
> import org.jboss.test.tomcat.ejb.interfaces.StatelessSessionHome;
>
> public class TestJBoss {
>
> public static void main(String[] args) {
>
> try
> {
> java.util.Hashtable properties = new java.util.Hashtable(3);
> properties.put(javax.naming.Context.PROVIDER_URL, "localhost");
> properties.put(javax.naming.Context.URL_PKG_PREFIXES,
"org.jboss.naming");
> properties.put(javax.naming.Context.INITIAL_CONTEXT_FACTORY,
>"org.jnp.interfaces.NamingContextFactory");
> InitialContext context = new InitialContext(properties);
>
> [...]
>
>
> Why the exception? Any help appreciated ...
>
> Kristoffer Larsson
>
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where is everyone today?
And if anyone bothers to check it, can someone please go thru the multiple datasources code I'd sent? It only makes sense to have it at a bean level - cannot think of an enterprise app connecting to single database! - Original Message - From: "Dain Sundstrom" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, June 29, 2001 8:22 PM Subject: RE: [JBoss-dev] Where is everyone today? > Jay, > > Great point. Up until I started on this code, no part of JBossCMP worked > with the other container objects (cache, invoker etc); JBossCMP was executed > by the container via the persistence store interface. I'm going to have to > think about this. > > Thanks for helping to clarify my bad feeling, > > -dain > > > -Original Message- > > From: Jay Walters [mailto:[EMAIL PROTECTED]] > > Sent: Friday, June 29, 2001 2:01 PM > > To: '[EMAIL PROTECTED]' > > Subject: RE: [JBoss-dev] Where is everyone today? > > > > > > I would think you'd want to be out of the guts too, that just > > seems a bit > > too closely coupled with JBoss for the persistence manager. > > Shouldn't the > > CMP persistence manager be some type of layer on top (well > > almost on top) > > with a well defined interface? This should clearly tie in to > > take advantage > > of what the container can provide. > > > > I am definitely on the outside of JBoss though, so marc et al > > are the people > > to listen to. > > > > Cheers > > > > -Original Message- > > From: Bill Burke [mailto:[EMAIL PROTECTED]] > > Sent: Friday, June 29, 2001 2:53 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] Where is everyone today? > > > > > > Yo Dain, > > > > I know absolutely nothing about CMP 2.x Relationships, but it makes me > > really worried that you are working directly with > > EntityEnterpriseContexts > > from the container.cache. Why aren't you going through the > > HOME interfaces > > to access related beans? Remember, each entity type can have entirely > > different datastores, caching mechanisms, locking mechanisms, > > synchronization mechanisms, and pooling mechanisms. You > > shouldn't really be > > circumventing how to access a bean. If I'm totally out of my > > league here, > > I'll just apologize and shut up. Let me know, but in the > > meantime, I'll try > > to review the CMP 2.x Relationships. > > > > Bill > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On > > Behalf Of Dain > > > Sundstrom > > > Sent: Friday, June 29, 2001 2:22 PM > > > To: '[EMAIL PROTECTED]' > > > Subject: [JBoss-dev] Where is everyone today? > > > > > > > > > Is everyone on vacation? Is the list working? What-ever, > > doesn't really > > > matter. > > > > > > If any one is around today, and can reply to my message, I > > would greatly > > > appreciate it. I kind of need some guidance on the decision > > to create an > > > interceptor or not. I'm going to continue along the line that I > > > don't need > > > an interceptor (I can always add it later). > > > > > > If you all are on vacation, have a great time. > > > > > > -dain > > > > > > > -Original Message- > > > > From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] > > > > Sent: Thursday, June 28, 2001 11:48 PM > > > > To: '[EMAIL PROTECTED]' > > > > Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > > > > > > > > > > marc, > > > > > > > > Do you mean that I should be setting invoked, or something else? > > > > > > > > I got the bi-directional one-to-one (enforced integrity) > > > > working using the > > > > entity cache, but it gives me a bad feeling. In the this > > > > case, there may be > > > > up to 4 beans that need to be stored: > > > > > > > > before: > > > > a1--b1 > > > > a2--b2 > > > > > > > > a1.setB(b2) > > > > > > > > after: > > > > a1\ b1 > > > > a2 \b2 > > > > > > > > So, I hold onto up to three other contexts. When my store is > > > > called, I write > > > > my state and then store the other contexts (with their > > > > respective mangers). > > > > This won't cause extraneous writes as 'tuned updates' is > > always on. > > > > > > > > What is giving me the bad feeling is I have just cut out all > > > > of the work > > > > that is being done in the interceptors, specifically > > > > EntitySynchronizationInterceptor. For example, do I need > > to remove the > > > > context from the cache at the end of the transaction? Do I > > > > need to lock the > > > > context? What if one of the beans is removed? (the new remove > > > > procedure for > > > > relationships may handle this, but haven't implemented it yet) > > > > > > > > As you can tell this has given me a lot of concern. If > > this is stuff I > > > > shouldn't worry about, good. If I should worry, will it be > > > > better to create > > > > the new interceptor, thus reusing the code in the other > > > > interceptors, or > > > > will it be easier to handle the few special cases in the > > > > persistence store? > > > > > > > > -dain > > > > > >
Re: [JBoss-dev] Shutting down JBoss
Well, Shutting down is on half of the story ain't it? You obviously want to restart the server you shut down at some point of time! I'll try going thru the these startup and shutdown classes and see if I can come up with anything! Thanks, Vinay PS: Thanks for the correcting the threads!=processes thing. just makes it easier to putting a ps -ef output as processes! - Original Message - From: "Bill Burke" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, June 29, 2001 8:10 PM Subject: RE: [JBoss-dev] Shutting down JBoss > Works great for me on Linux. > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron > > Mulder > > Sent: Friday, June 29, 2001 2:56 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] Shutting down JBoss > > > > > > On Fri, 29 Jun 2001, Bill Burke wrote: > > > You can shut it down very easy from the JMX interface. Starting up is a > > > different story. > > > > Last time I tried this, it unloaded all the beans and services, > > but did not actually cause the JVM to exit, so JBoss was still taking a > > boatload of system resources. Is there a "shutdown and exit" option now? > > > > Aaron > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Shutting down JBoss
Alright, This might sound a bit naive but do we need a little simple gui that one can use to shut down JBoss or restart it? When you run JBoss on the command line in Unix as a background process [./run.sh&] it spawns loads of java processes that need to be killed. Is there a cleaner way to do this? Vinay
[JBoss-dev] Code: Multiple Datasources in JAWS
Hello,
After moaning about this for a couple of days, I got myself to write the
bit to have bean level datasources.The changes to JawsEntityMetaData are
1. To read the 'datasource' tag at bean level
//get the datasouce name
String dataSourceName = getElementContent(getOptionalChild(element,
"datasource"));
//if a local datasource name is found bind it and set the local
datasource
if(dataSourceName!=null)
{
// Make sure it is prefixed with java:
if (!dataSourceName.startsWith("java:/"))
dataSourceName = "java:/"+dataSourceName;
// find the datasource
if (! dataSourceName.startsWith("jdbc:")) {
try {
this.dataSource = (DataSource)new
InitialContext().lookup(dataSourceName);
} catch (NamingException e) {
throw new DeploymentException(e.getMessage());
}
}
}
2. To return the appropriate datasource
//Return appropriate datasource
public DataSource getDataSource()
{
//If a local datasource has been specified use it
if(this.dataSource!=null)
{
return dataSource;
}
//Use the gloabal datasource
else
{
return jawsApplication.getDataSource();
}
}
So basically for a jaws.xml that starts as
java:/PERSONAL
false
Oracle8
PieParamEntity
java:/BRILLOBER
it will use the BRILLOBER datasource if it has been specified and use the
global on i.e PERSONAL if the datasource tag has not been specified at the
bean level. Do we want to check this in?
Regards
Vinay
PS: For those who want to patch this into their set up and try using it the
entire file follows
/*
* JBoss, the OpenSource EJB server
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.ejb.plugins.jaws.metadata;
import java.util.ArrayList;
import java.util.Hashtable;
import java.util.Iterator;
import java.util.HashMap;
import java.lang.reflect.Field;
import javax.sql.DataSource;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.naming.InitialContext;
import org.w3c.dom.Element;
import org.jboss.ejb.DeploymentException;
import org.jboss.metadata.EntityMetaData;
import org.jboss.metadata.MetaData;
import org.jboss.metadata.XmlLoadable;
// TODO
import org.jboss.logging.Logger;
/**
*
*
* @see
* @author Sebastien Alborini
* @author mailto:[EMAIL PROTECTED]";>Dirk Zimmermann
* @author mailto:[EMAIL PROTECTED]";>Vinay Menon
* @version $Revision: 1.9 $
*/
public class JawsEntityMetaData extends MetaData implements XmlLoadable {
// Constants -
// Attributes
// parent metadata structures
private JawsApplicationMetaData jawsApplication;
private EntityMetaData entity;
// the name of the bean (same as entity.getEjbName())
private String ejbName = null;
// the name of the table to use for this bean
private String tableName = null;
// do we have to try and create the table on deployment?
private boolean createTable;
// do we have to drop the table on undeployment?
private boolean removeTable;
// do we use tuned updates?
private boolean tunedUpdates;
// do we use 'SELECT ... FOR UPDATE' syntax?
private boolean selectForUpdate;
// is the bean read-only?
private boolean readOnly;
//Added by Vinay Menon - Start
//Enable fast updates based on stable row id column
private String stableRowIdColumn;
//Added by Vinay Menon - End
private int timeOut;
// should the table have a primary key constraint?
private boolean pkConstraint;
// is the bean's primary key a composite object
private boolean compositeKey;
// the class of the primary key
private Class primaryKeyClass;
// the datasource name - Vinay
private DataSource dataSource=null;
// the fields we must persist for this bean
private Hashtable cmpFields = new Hashtable();
// the fields that belong to the primary key (if composite)
private ArrayList pkFields = new ArrayList();
// finders for this bean
private ArrayList finders = new ArrayList();
/**
* Here we store the basename of all detailed fields in jaws.xml
* (e.g., "data" for "data.categoryPK").
*/
private HashMap detailedFieldDescriptions = new HashMap();
/**
* This is the Boolean we store as value in detailedFieldDescriptions.
*/
private static final Boolean detailedBoolean = new Boolean(true);
// Static
// Constructors --
public JawsEntityMetaData(JawsApplicationMetaData app, EntityMetaData ent)
throws DeploymentException {
// initialisa
Re: [JBoss-dev] JBoss CVS
Branch_2_4 is the one for 2.4 and the trunk is currently JBoss 3.0 stuff. Someone kick me if I am wrong or asleep. Vinay - Original Message - From: "Bill Burke" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 28, 2001 12:30 AM Subject: RE: [JBoss-dev] JBoss CVS > There is a 2.4 branch, the mainline is JBoss 3.0. > > See archives for specifics. > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Vinay > > Menon > > Sent: Wednesday, June 27, 2001 7:17 PM > > To: Dev @ JBoss > > Subject: [JBoss-dev] JBoss CVS > > > > > > Do we now have a branch in CVS for JBoss 3.0 [Rabbithole?] and is > > the one on > > the trunk JBoss 2.4.0? > > > > Vinay > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss CVS
Do we now have a branch in CVS for JBoss 3.0 [Rabbithole?] and is the one on the trunk JBoss 2.4.0? Vinay ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
I believe Oracle actually throws an exception if you had an existing transaction and you tried to fool around with the transaction setting. Vinay - Original Message - From: "marc fleury" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 27, 2001 5:19 AM Subject: RE: [JBoss-dev] High load... > |I think you missed one of the old messages (way to many today). > | > |It appears that if you changes the transaction isolation in the middle of a > |transaction the driver can perform an implicit commit (YUCK). > | > |So, I don't think we can trust drivers to allows us to change the level on > |the fly. > > well that is EXCELLENT NEWS... ? > > you are saying that I can actually change the isolation level on a jdbc > connection for a new transaction ? ( I don't want to change in the middle) > what I want to do is > > connection A gets assigned to transaction B > > transaction B encompasses bean C > > The container gets connection D > > Connection D was use with bean E previously > > bean C is ISOLATION1 and D is ISOLATION2 > > my question is can we reconfigure connection D with the new stuff? > > you seem to say that yes...because you are aware of problems that arise if > we do it INSIDE a transaction, when I really don't care about this fine a > feature... > > marcf > > | > |-dain > |- Original Message - > |From: "marc fleury" <[EMAIL PROTECTED]> > |To: <[EMAIL PROTECTED]> > |Sent: Tuesday, June 26, 2001 10:36 PM > |Subject: RE: [JBoss-dev] High load... > | > | > |> |> Sure, it would be useful to be able to specify different levels per > |> |> bean, but given the apparent constraints that the databases > |are putting > |> |> us under, implementing it against the database isn't feasable. > |> |> > |> | > |> |Just use a freakin' different connection pool for different beans and > |there > |> |is no freakin' database constraint. > |> > |> oh wait reading old stuff, so you are saying that > |> > |> (do jdbc connection support setIsolationlevel on the fly) == false > |> > |> shit... > |> > |> databases is an UGLY world, you know what??? we can do MUCH better at the > |> distributed cache level so screw delegating to the db... > |> > |> I am drunk and it is getting tough to think ... > |> > |> marcf > |> > |> > |> > |> ___ > |> Jboss-development mailing list > |> [EMAIL PROTECTED] > |> http://lists.sourceforge.net/lists/listinfo/jboss-development > |> > | > | > |___ > |Jboss-development mailing list > |[EMAIL PROTECTED] > |http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Clustering Support in JBoss
Marc, I know that someone from London is working on enabling clustering support for JBoss - was wondering if a) we have made any progress b) if I could get involved in that. Vinay ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] does it really works ?
Strong words I must say! If you have a quick list of exact errors you are getting, mail them to me. I'd just like to try helping you to make my point that JBoss is not vaporware and *not* a joke. Vinay - Original Message - From: jean To: [EMAIL PROTECTED] Sent: Wednesday, June 27, 2001 6:58 PM Subject: [JBoss-dev] does it really works ? JBoss-2.4-BETA_Tomcat-3.2.2.zip 9.7M June 23, 2001 ; Does it really work ?( JBoss + Tomcat Packages) , Hello folks does JB+T really can work ? I have download avery downloadble version, and configure it the way it is describes, but nothing seems to work,I use win2000 prof, jdk1.4, what can be the problem ? or it is just lot of Jboss +Tomcat.zip, but in reallity it doesn't work ? I can't launche tomcat when I launched JBoss. This Jboss business is it a joke ? any good example of how to run Tomcat with Jboss is welcomed. thanks
Re: [JBoss-dev] JAWS -Single Datasource
Yes! Guess it should figure in the training course! Vinay - Original Message - From: "marc fleury" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 25, 2001 3:30 PM Subject: RE: [JBoss-dev] JAWS -Single Datasource > |Nonetheless, it would be great if the new CMP stuff will be able to > |support multiple datasources i.e. move the datasource from a JAWS file > |level node to a bean level value. > > I should really add a slide in the training called "scratch your own itch, > Open Source's dirty little secret"... > > You want it? bad? > > You know what to do > > marcf > > | > |Thanks > | > |Vinay > | > |marc fleury wrote: > |> > |> Not all configuration cases will uses transactions across different > |> databases (i.e. really require XA synchronization). > |> > |> The case Vinay is talking about is fairly simple simple 2 beans, > |2 different > |> apps (they don't talk to each other so no transaction enrollment), 2 > |> different databases, which is a perfectly valid approach to web container > |> app design, in fact a smart way to handle the database access > |from your web > |> layers ( and teh real reason I suspect he is asking for this feature). > |> > |> Distributed transaction is another ball game altogether, but what he is > |> asking for doesn't necessarily require that. Also he has been through my > |> training and he knows that distributed transactions are bad mkey? > |> > |> In short it is a very valid feature Vinay, as everyone told you (dain, > |> danch), why don't you go ahead and hack the metadata code to > |make sure you > |> can support multiple datasources (I am surprised it is not there yet). > |> > |> Talk to sebastien if you need help on that code, he wrote it. > |> > |> regards > |> marcf > |> > |> |-Original Message- > |> |From: [EMAIL PROTECTED] > |> |[mailto:[EMAIL PROTECTED]]On Behalf Of danch > |> |Sent: Sunday, June 24, 2001 11:58 PM > |> |To: [EMAIL PROTECTED] > |> |Subject: Re: [JBoss-dev] JAWS -Single Datasource > |> | > |> | > |> |Dain Sundstrom wrote: > |> | > |> |> No reason to tie an entire jar to a single datasource. I'll > |> |check my code > |> |> to see if it can support multiple datasources, although I > |don't think it > |> |> will work with most DBs. This would require the DBs to > |natively support > |> |> JDBC 2.0 XA transactions, and if I remember most DBs don't > |have 2-phase > |> |> commit drivers yet. > |> |> > |> |> -dain > |> | > |> |I believe they are getting much closer (at least if implementations of > |> |the XA extensions to JDBC are a true indicator). Of course, many of the > |> |XA implementations are broken in incompatible ways. > |> | > |> |Also, this wouldn't matter so long as the beans that are in different > |> |databases are in different transactions. But then there'd be no reason > |> |not to split them into different ejb-jar files. > |> | > |> |-danch > |> | > |> | > |> |___ > |> |Jboss-development mailing list > |> |[EMAIL PROTECTED] > |> |http://lists.sourceforge.net/lists/listinfo/jboss-development > |> > |> ___ > |> Jboss-development mailing list > |> [EMAIL PROTECTED] > |> http://lists.sourceforge.net/lists/listinfo/jboss-development > | > |___ > |Jboss-development mailing list > |[EMAIL PROTECTED] > |http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Shall I check in code for the ROWID thingey??????
Georg, Great, I'd sent the files across as is, but will repost it with this diff thingey. Let me see if I can get it sent today! Cheers Vinay PS: Have been guilty of not checking my list mails for a couple of days now. - Original Message - From: "Georg Rehfeld" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 25, 2001 11:29 PM Subject: Re: [JBoss-dev] Shall I check in code for the ROWID thingey?? > Hi Vinay, > > > Has anyone bothered to go thru the ROWID based update code I'd > > sent out? I would really want to check it in but don't want to do > > so without a go ahead lest it affect any other portion of the > > server. If you want me to repost the diff code please let me > > know and I can do that. > > Oops, I'm sorry, I promised to do and didn't do that (see PS). > Please resend, and PLEASE send us/me a unified diff with enough > context lines by doing: > > prompt> cd $JBOSS_HOME > prompt> cvs diff -u [ > in ASCII instead of HTML to ease the job. > > Thanks, I'll review then, > Georg > ___ ___ > | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg > |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 > > PS: my current employer seems to be out of money, so I had to do > some DB teaching and I'm just about to accept a PERL/CGI job > to earn my next lease instead of doing really good stuff. > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JAWS -Single Datasource
Yes Marc, That exactly is the point. The only work around I could think of was to jar the different apps separately and put them in a single EAR so that the deployment unit is still one bundle but with different jars. Nonetheless, it would be great if the new CMP stuff will be able to support multiple datasources i.e. move the datasource from a JAWS file level node to a bean level value. Thanks Vinay marc fleury wrote: > > Not all configuration cases will uses transactions across different > databases (i.e. really require XA synchronization). > > The case Vinay is talking about is fairly simple simple 2 beans, 2 different > apps (they don't talk to each other so no transaction enrollment), 2 > different databases, which is a perfectly valid approach to web container > app design, in fact a smart way to handle the database access from your web > layers ( and teh real reason I suspect he is asking for this feature). > > Distributed transaction is another ball game altogether, but what he is > asking for doesn't necessarily require that. Also he has been through my > training and he knows that distributed transactions are bad mkey? > > In short it is a very valid feature Vinay, as everyone told you (dain, > danch), why don't you go ahead and hack the metadata code to make sure you > can support multiple datasources (I am surprised it is not there yet). > > Talk to sebastien if you need help on that code, he wrote it. > > regards > marcf > > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of danch > |Sent: Sunday, June 24, 2001 11:58 PM > |To: [EMAIL PROTECTED] > |Subject: Re: [JBoss-dev] JAWS -Single Datasource > | > | > |Dain Sundstrom wrote: > | > |> No reason to tie an entire jar to a single datasource. I'll > |check my code > |> to see if it can support multiple datasources, although I don't think it > |> will work with most DBs. This would require the DBs to natively support > |> JDBC 2.0 XA transactions, and if I remember most DBs don't have 2-phase > |> commit drivers yet. > |> > |> -dain > | > |I believe they are getting much closer (at least if implementations of > |the XA extensions to JDBC are a true indicator). Of course, many of the > |XA implementations are broken in incompatible ways. > | > |Also, this wouldn't matter so long as the beans that are in different > |databases are in different transactions. But then there'd be no reason > |not to split them into different ejb-jar files. > | > |-danch > | > | > |___ > |Jboss-development mailing list > |[EMAIL PROTECTED] > |http://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Fast ROWID Updates - REPOST
Alright,
Have modified the Store Command to default to the priamary key
if the row id is null. I am surprised that am not getting the ROWID as
null anywhere except for in the ejbPostCreate method. If everyone is
happy with the way its been done in JDBCStoreEntityCommand, then please
give me a shout and I can do the same for the JDBCRemoveEntityCommand as
well. Alternatively, if there is something glaringly wrong then let me
know so that I can fix it.
Regards
Vinay
Here is the code.
1. Adding a field in jaws.xml called stable-rowid-column name. This is
ROWID for Oracle and can be something else for other databases. If you
do not
want to use this feature just don't specify the tag and it will use the
default mechansm based on the primary key.
2. Updated JawsEntityMetaData with
//Enable fast updates based on stable row id column
private String stableRowIdColumn;
public String getStableRowIdColumn() { return stableRowIdColumn; }
//Get row id for fast stable row id based updates/deletes and
inserts
stableRowIdColumn = getElementContent(getOptionalChild(element,
"stable-rowid-column"));
3. Modified JDBCStoreEntityCommand as follows,
/*
* JBoss, the OpenSource EJB server
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.ejb.plugins.jaws.jdbc;
import java.lang.reflect.Field;
import java.util.Iterator;
import java.rmi.RemoteException;
import java.rmi.ServerException;
import java.sql.PreparedStatement;
import org.jboss.ejb.EntityEnterpriseContext;
import org.jboss.ejb.plugins.jaws.JAWSPersistenceManager;
import org.jboss.ejb.plugins.jaws.JPMStoreEntityCommand;
import org.jboss.ejb.plugins.jaws.metadata.CMPFieldMetaData;
/**
* JAWSPersistenceManager JDBCStoreEntityCommand
*
* @see
* @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>Joe Shevland
* @author mailto:[EMAIL PROTECTED]";>Justin Forder
* @author mailto:[EMAIL PROTECTED]";>Sebastien
Alborini
* @author mailto:[EMAIL PROTECTED]";>Vinay Menon
* @version $Revision: 1.7 $
*/
public class JDBCStoreEntityCommand
extends JDBCUpdateCommand
implements JPMStoreEntityCommand
{
// Constructors --
public JDBCStoreEntityCommand(JDBCCommandFactory factory)
{
super(factory, "Store");
boolean tuned = jawsEntity.hasTunedUpdates();
// If we don't have tuned updates, create static SQL
if (!tuned)
{
setSQL(makeSQL(null));
}
}
// JPMStoreEntityCommand implementation ---
/**
* if the readOnly flag is specified in the xml file this won't
store.
* if not a tuned or untuned update is issued.
*/
public void execute(EntityEnterpriseContext ctx)
throws RemoteException
{
// Check for read-only
// JF: Shouldn't this throw an exception?
if (jawsEntity.isReadOnly())
{
return;
}
ExecutionState es = new ExecutionState();
es.ctx = ctx;
es.currentState = getState(ctx);
boolean dirty = false;
boolean tuned = jawsEntity.hasTunedUpdates();
// For tuned updates, need to see which fields have changed
if (tuned)
{
es.dirtyField = new boolean[es.currentState.length];
Object[] oldState =
((JAWSPersistenceManager.PersistenceContext)ctx.getPersistenceContext()).state;
for (int i = 0; i < es.currentState.length; i++)
{
es.dirtyField[i] = changed(es.currentState[i], oldState[i]);
dirty |= es.dirtyField[i];
}
}
if (!tuned || dirty)
{
try
{
// Update db
jdbcExecute(es);
} catch (Exception e)
{
throw new ServerException("Store failed", e);
}
}
}
// JDBCUpdateCommand overrides ---
/**
* Returns dynamically-generated SQL if this entity
* has tuned updates, otherwise static SQL.
*/
protected String getSQL(Object argOrArgs) throws Exception
{
boolean tuned = jawsEntity.hasTunedUpdates();
String sql = tuned ? makeSQL(argOrArgs) :
super.getSQL(argOrArgs);
return sql;
}
protected void setParameters(PreparedStatement stmt, Object
argOrArgs)
throws Exception
{
ExecutionState es = (ExecutionState)argOrArgs;
boolean tuned = jawsEntity.hasTunedUpdates();
int idx = 1;
Iterator iter = jawsEntity.getCMPFields();
int i = 0;
//Modified by Vinay Menon - Start
String stableRowIdColumn = jawsEntity.getStableRowIdColumn();
/**
* Will store the actual value for the stable row id column
* and the JDBC type for this column
*/
[JBoss-dev] Shall I check in code for the ROWID thingey??????
Hello All, Has anyone bothered to go thru the ROWID based update code I'd sent out? I would really want to check it in but don't want to do so without a go ahead lest it affect any other portion of the server. If you want me to re-post the diff code please let me know and I can do that. VinayGet more from the Web. FREE MSN Explorer download : http://explorer.msn.com
[JBoss-dev] JAWS -Single Datasource
Hello, Is there any specific reason why the tag needs to be applicable to the entire JAWS xml? This would mean that all the beans essentially tie to the same datasource i.e. database and need splitting up of the application into smaller units with their own separate deployement descriptors. Or am I missing something? VinayGet more from the Web. FREE MSN Explorer download : http://explorer.msn.com
Re: [JBoss-dev] ROWID Based Update: Load Entity Before Store Entity
I am trying against JBoss 2.4 BETA [as it says when it starts up] and the
bean is a CMP bean. I have tried all 4 commit options and have debug
statements in the StoreEntityCommand to detect cases where the ROWID is
coming thru as a null as
System.out.println(" -- Stable RowID is "+
stableRowIdColumnValue +" -- ");
if(stableRowIdColumnValue == null)
{
System.out.println(" --- Oops! The Row ID is NULL --- ");
System.out.println(" --- Regenrate SQL and call
setParameters again --- ");
String sql = makeSQL(argOrArgs,true);
stmt = stmt.getConnection().prepareStatement(sql);
setParameters(stmt,argOrArgs);
return;
}
And that portion of the code has never executed! Let me try tracking the
transactions at play and get back to you.
Vinay
- Original Message -
From: "Georg Rehfeld" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, June 16, 2001 3:37 AM
Subject: Re: [JBoss-dev] ROWID Based Update: Load Entity Before Store Entity
> Hi Vinay, hi all,
>
> Vinay:
> >>> This basically means that even within the same transaction the
> >>> rowid will be updated if the client attempts to do an update
> >>> [or delete].
>
> >>> Do we now need to check for rowid being null and falling back
> >>> to the primary key if it is not? I had written some code for
> >>> this and was surprised that it was never being called.
>
> Georg:
> >> Which commit option was set for your entity bean? If it were B
> >> or C, it's clear, that the instance is loaded within a TX, but
> >> with A and with B (outside TX) the load should NOT happen, thus
> >> the check for a null rowidValue would be better.
>
> Vinay:
> > Nope! That is what I thought as well. The bean *is* being loaded
> > even with commit options A and B, for the same operation with the
> > transactions settings remaining the same.
>
> If you are right, I would consider it a bug, rendering commit
> option A and B useless, which promise bean caching. And I checked
> against binary JBoss 2.2.1, BMP, commit option A and Requires:
>
> DEFINITELY the sequence of calls when creating an Entity bean is
> TX 1
> | - setEntityContext()
> | - ejbCreate()
> | - ejbPostCreate()
> TX 2
> | -
> | -
> | - ejbStore()
>
> As you see, there is NO ejbLoad() between ejbPostCreate() and
> the business methods, in fact ejbLoad() on this bean is NEVER
> called, except after passivation/reactivation, as expected.
>
> This same behaviour should be seen also with CMP!
>
> If this behaviour has changed with the current CVS JBoss there
> must be some problem been introduced.
>
> regards
> Georg
> ___ ___
> | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg
> |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10
>
> PS: Sorry, I just can't test with the CVS version.
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBOSS.ORG back online on JBOSS/TOMCAT
Looks good Marc! The following like does not work : http://www.jboss.org/documentation/ECperf.html Vinay - Original Message - From: "marc fleury" <[EMAIL PROTECTED]> To: "Jboss-Development@Lists. Sourceforge. Net" <[EMAIL PROTECTED]>; "Jboss-User@Lists. Sourceforge. Net" <[EMAIL PROTECTED]> Sent: Friday, June 15, 2001 4:09 PM Subject: [JBoss-dev] JBOSS.ORG back online on JBOSS/TOMCAT > A big, sloppy, thank you thank you thank you to the French Brigade at > Telecom Paris for being alert and helping out in "firefighter" mode. > Sebastien fixed it.. > > Sebastien you the man, discreet as ever, but there when it really really > counts... > > thanks man... > > so anyway... jboss.org is back online and it is all running on JBoss/Tomcat. > Pure JSP etc etc... > > thanks to those who helped out and regards > > marcf > > PS: come on come on go try it out already ! > > _ > Marc Fleury, Ph.D > [EMAIL PROTECTED] > _ > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss on JBoss
am not arguing about why we can't use Apache. Just saying that after a lot of benchmarking and stuff the web server on tomcat was lacking. It has nothing to do with me running the site! as for tomcat - go ahead! I can help in whatever way I can ... but the performance on 8080 sucks! I stand by that. Vinay - Original Message - From: "marc fleury" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, June 15, 2001 2:02 PM Subject: RE: [JBoss-dev] JBoss on JBoss > and you gonna run it for me? unless you put your work on the line, don't put > your mouth and opinions in front > > I just realized I updated the cvs and the procedures wiped out the current > cvs so we REALLY have to make the switch now... prematurely but so it > goes... > > that is when I close my eyes and take a leap of faith. > > Tomcat better not let me down... you guys better help if Tomcat does go > down... > > marcf > > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of K.V. > |Vinay Menon > |Sent: Friday, June 15, 2001 4:12 AM > |To: [EMAIL PROTECTED] > |Subject: Re: [JBoss-dev] JBoss on JBoss > | > | > |I seem to agree with Jay. The web server in Tomcat sucks. It is very slow! > | > |Vinay > |- Original Message - > |From: "Jay Walters" <[EMAIL PROTECTED]> > |To: "'Schaefer, Andreas '" <[EMAIL PROTECTED]>; > |<[EMAIL PROTECTED]> > |Sent: Friday, June 15, 2001 1:34 AM > |Subject: RE: [JBoss-dev] JBoss on JBoss > | > | > |> I fail to see how serving .gif files from tomcat shows off > |jboss. i am all > |> for using jboss to handle dynamic content on the site, just trying to > |figure > |> out why every hit has to go there. Is that how you expect people to use > |it > |> > |> Cheers > |> > |> -Original Message- > |> From: Schaefer, Andreas > |> To: '[EMAIL PROTECTED]' > |> Sent: 6/14/01 1:34 PM > |> Subject: RE: [JBoss-dev] JBoss on JBoss > |> > |> What a question ! > |> > |> How do you want to convince other people to use JBoss when > |> you aren't going to use your own tool. Either JBoss is > |> ready to be used in production and then we should use it. > |> > |> BTW We are going to create an interactive Survey which > |> must store the info in a DB. > |> > |> Mad Andy > |> > |> > -Original Message- > |> > From: Jay Walters [mailto:[EMAIL PROTECTED]] > |> > Sent: Thursday, June 14, 2001 9:05 AM > |> > To: '[EMAIL PROTECTED]' > |> > Subject: RE: [JBoss-dev] JBoss on JBoss > |> > > |> > > |> > Why the decision to remove apache and serve everything from tomcat? > |> > > |> > Cheers > |> > > |> > -Original Message- > |> > From: marc fleury [mailto:[EMAIL PROTECTED]] > |> > Sent: Thursday, June 14, 2001 11:50 AM > |> > To: Jboss-Development@Lists. Sourceforge. Net; Jboss-User@Lists. > |> > Sourceforge. Net > |> > Subject: [JBoss-dev] JBoss on JBoss > |> > > |> > > |> > since I am done porting the website and adding a few things, > |> > it will run on > |> > JBoss/Tomcat now. > |> > > |> > However not all is ported yet, most notably petstore is > |> > finicky and the > |> > order in which we deploy the ears is important (go figure). > |> > > |> > So bear with us and the website as we move all this online. > |> > Also JIVE will > |> > be installed and jboss-user going online soon. Time to taste our own > |> > medicine. If we are going to evangelize on our technology we > |> > better have > |> > the track record *at home* to support it. > |> > > |> > Again for the next few days the website will be a little > |> > messy and under > |> > construction, thanks for your understanding, > |> > > |> > regards > |> > > |> > marcf > |> > > |> > _ > |> > Marc Fleury, Ph.D > |> > [EMAIL PROTECTED] > |> > _ > |> > > |> > > |> > > |> > ___ > |> > Jboss-development mailing list > |> > [EMAIL PROTECTED] > |> > http://lists.sourceforge.net/lists/listinfo/jboss-development > |> > > |> > ___ > |> > Jboss-development mailing list > |> > [EMAIL PROTECTED] > |> > http://lists.sourcefo
Re: [JBoss-dev] Is Monday still a good 2.4 freeze date
I would have liked to have added the ROWID bit, but don't want to rush it thru! Vinay - Original Message - From: "Scott M Stark" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, June 15, 2001 9:09 AM Subject: Re: [JBoss-dev] Is Monday still a good 2.4 freeze date > This is just a suprious exception that can easily be cleaned up. > Its also just a feature freeze to create the 2.4 branch, not a 2.4 > release build as Juha said. The first release on the 2.4 branch > will be a beta. > > - Original Message - > From: "Vincent Harcq" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, June 15, 2001 12:20 AM > Subject: RE: [JBoss-dev] Is Monday still a good 2.4 freeze date > > > > Hi, > > IMHO, the re-deployment problem (see below) should stop you making a new > > release. > > > > For my part, I will test/validate the new DTD validation option as some > > elements are still missing from jaws.dtd (cmp-field is not defined). I will > > take care of dtd corrections. > > > > Vincent. > > > > [Container Management Proxy] Destroyed > > [Default] javax.management.InstanceAlreadyExistsException: > > Management:container=bank/Account > > [Default] at > > com.sun.management.jmx.RepositorySupport.addMBean(RepositorySupport.java:134 > > ) > > [Default] > > [Default] at > > com.sun.management.jmx.MBeanServerImpl.internal_addObject(MBeanServerImpl.ja > > va: > > [Default] > > [Default] at > > com.sun.management.jmx.MBeanServerImpl.createMBean(MBeanServerImpl.java:388) > > [Default] > > [Default] at > > org.jboss.ejb.ContainerFactory.registerContainer(ContainerFactory.java:716) > > [Default] > > [Default] at > > org.jboss.ejb.ContainerFactory.createEntityContainer(ContainerFactory.java:7 > > 00) > > [Default] > > [Default] at > > org.jboss.ejb.ContainerFactory.createContainer(ContainerFactory.java:599) > > [Default] > > [Default] at > > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:471) > > [Default] > > [Default] at > > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:366) > > [Default] > > [Default] at > > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:305) > > [Default] > > [Default] at java.lang.reflect.Method.invoke(Native Method) > > [Default] > > [Default] at > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) > > [Default] > > [Default] at > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) > > [Default] > > [Default] at > > org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:489) > > [Default] > > [Default] at > > org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:467) > > [Default] > > [Default] at > > org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:211) > > [Default] > > [Default] at java.lang.reflect.Method.invoke(Native Method) > > [Default] > > [Default] at > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) > > [Default] > > [Default] at > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) > > [Default] > > [Default] at org.jboss.ejb.AutoDeployer.deploy(AutoDeployer.java:379) > > [Default] > > [Default] at org.jboss.ejb.AutoDeployer.run(AutoDeployer.java:217) > > [Default] > > [Default] at java.lang.Thread.run(Unknown Source) > > [Default] > > > > > -Message d'origine- > > > De : [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]De la part de > > > Scott M Stark > > > Envoyé : vendredi 15 juin 2001 2:24 > > > À : JBoss Dev > > > Objet : [JBoss-dev] Is Monday still a good 2.4 freeze date > > > > > > > > > Is Monday still a good 2.4 freeze date for the features that will go into > > > the 2.4 release or is more time needed? > > > > > > > > > > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > _ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss on JBoss
I seem to agree with Jay. The web server in Tomcat sucks. It is very slow! Vinay - Original Message - From: "Jay Walters" <[EMAIL PROTECTED]> To: "'Schaefer, Andreas '" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, June 15, 2001 1:34 AM Subject: RE: [JBoss-dev] JBoss on JBoss > I fail to see how serving .gif files from tomcat shows off jboss. i am all > for using jboss to handle dynamic content on the site, just trying to figure > out why every hit has to go there. Is that how you expect people to use it > > Cheers > > -Original Message- > From: Schaefer, Andreas > To: '[EMAIL PROTECTED]' > Sent: 6/14/01 1:34 PM > Subject: RE: [JBoss-dev] JBoss on JBoss > > What a question ! > > How do you want to convince other people to use JBoss when > you aren't going to use your own tool. Either JBoss is > ready to be used in production and then we should use it. > > BTW We are going to create an interactive Survey which > must store the info in a DB. > > Mad Andy > > > -Original Message- > > From: Jay Walters [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, June 14, 2001 9:05 AM > > To: '[EMAIL PROTECTED]' > > Subject: RE: [JBoss-dev] JBoss on JBoss > > > > > > Why the decision to remove apache and serve everything from tomcat? > > > > Cheers > > > > -Original Message- > > From: marc fleury [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, June 14, 2001 11:50 AM > > To: Jboss-Development@Lists. Sourceforge. Net; Jboss-User@Lists. > > Sourceforge. Net > > Subject: [JBoss-dev] JBoss on JBoss > > > > > > since I am done porting the website and adding a few things, > > it will run on > > JBoss/Tomcat now. > > > > However not all is ported yet, most notably petstore is > > finicky and the > > order in which we deploy the ears is important (go figure). > > > > So bear with us and the website as we move all this online. > > Also JIVE will > > be installed and jboss-user going online soon. Time to taste our own > > medicine. If we are going to evangelize on our technology we > > better have > > the track record *at home* to support it. > > > > Again for the next few days the website will be a little > > messy and under > > construction, thanks for your understanding, > > > > regards > > > > marcf > > > > _ > > Marc Fleury, Ph.D > > [EMAIL PROTECTED] > > _ > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ROWID Based Update: Load Entity Before Store Entity
Hello Georg, Nope! That is what I thought as well. The bean *is* being loaded even with commit options A and B, for the same operation with the transactions settings remaining the same. Vinay - Original Message - From: Georg Rehfeld To: [EMAIL PROTECTED] Sent: Friday, June 15, 2001 1:02 AM Subject: Re: [JBoss-dev] ROWID Based Update: Load Entity Before Store Entity Hi Vinay,> This basically means that even within the same transaction the > rowid will be updated if the client attempts to do an update > [or delete].> Do we now need to check for rowid being null and falling back > to the primary key if it is not? I had written some code for > this and was surprised that it was never being called. Which commit option was set for your entity bean? If it were B or C, it's clear, that the instance is loaded within a TX, butwith A and with B (outside TX) the load should NOT happen, thusthe check for a null rowidValue would be better.regardsGeorg ___ ___| + | |__ Georg Rehfeld Woltmanstr. 12 20097 Hamburg|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10___Jboss-development mailing list[EMAIL PROTECTED]http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ROWID Based Update: Load Entity Before Store Entity
Damn, i had set it to plain text. Sorry jbossers! Vinay PS: Marc pls don't send me a stinker! - Original Message - From: "Juha Lindfors" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 14, 2001 4:52 PM Subject: Re: [JBoss-dev] ROWID Based Update: Load Entity Before Store Entity > > Vinay, > > you're still sending HTML :( > > -- Juha > > At 15:24 14.6.2001 +0100, you wrote: > > Hello,a code change for handling updates which happen in the > >sam > > > > > > > > > > > > > > > >e trsaction ashe insert. Here is what > >Iound: > > > > > >1. > >I > >he > >a > >Session > >Bean fronting an Entity Bean. > >The > >methods > >in > >the > >Session > >bean > >is > >have > >container transaction set > >to > > > >'RequriesNew' > >and > >the methods > >in > >the > >Entity > >Bean > >have > >container > >transaction set to > >'Requires' > >So > >I'd > >assume > >the > >call to > >be like > >> > Commit 3. > >Alrht, the > >way > >the > >methods > >are > >being > >called for > >different commit > >options are > >as > >--- > >Creating > >Call > >w > > > >--- > >[Default] > >JCCommand > >Executing: > >SELECT > >COUNT(*) > >FROM > >itemizedcall > >WHERE > >accountnumber=? > >AND > >mobilenumber=? > >AND > >invoicenumber=? > >AND > > > >itemizedcallnumber=? > >[Default] > >JDBCCommand > >Executing: > >INSERT > >INTO > > > >itemizedcall > > > >(itemizedcallnumber,callcost,callduration,mobilenumber,accountnumber,invoic > enumber,calltype) VALUES (?,?,?,?,?,?,?) > > --- Post Create for Entity Bean Now --- > > -- Load Entity -- > > -- > > --- Setting Call Cost Now --- > > -- Store Entity -- > >[Default] JDBCCommand Executing: UPDATE itemizedcall SET > >itemizedcallnumber=?,callcost=?,callduration=?,mobilenumber=?,accountnumber > =?,invoicenumber=?,calltype=? WHERE ROWID =? > > delete]. If we are happy with this I'd like to commit this to > >CVS. Regards Vinay > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] ROWID Based Update: Load Entity Before Store Entity [Plain Text!]
Hello, Had sometime to review the rowid based update code and was wondering whether or not to do a code change for handling updates which happen in the same transaction as the insert. Here is what I found: 1. I have a Session Bean fronting an Entity Bean. The methods in the Session bean is have container transaction set to 'RequriesNew' and the methods in the Entity Bean have container transaction set to 'Requires' 2. The business method in the session bean creates an entity bean within the same method. So I'd assume the call to be like Call ---> [RequiresNew] Start Transaction --> Call create method on Entity Bean --> [Requires] Stick to current transaction --> Call set method on entity bean created --> [Requires] Stick to current transaction --> Commit 3. Alright, the way the methods are being called for different commit options are as [Default] --- Creating Call Now --- [Default] JDBCCommand Executing: SELECT COUNT(*) FROM itemizedcall WHERE accountnumber=? AND mobilenumber=? AND invoicenumber=? AND itemizedcallnumber=? [Default] JDBCCommand Executing: INSERT INTO itemizedcall (itemizedcallnumber,callcost,callduration,mobilenumber,accountnumber,invoice number,calltype) VALUES (?,?,?,?,?,?,?) [Default] --- Post Create for Entity Bean Now --- [Default] -- Load Entity -- [Default] -- Invoke Load -- [Default] --- Setting Call Cost Now --- [Default] -- Store Entity -- [Default] JDBCCommand Executing: UPDATE itemizedcall SET itemizedcallnumber=?,callcost=?,callduration=?,mobilenumber=?,accountnumber= ?,invoicenumber=?,calltype=? WHERE ROWID =? This basically means that even within the same transaction the rowid will be updated if the client attempts to do an update [or delete]. Do we now need to check for rowid being null and falling back to the primary key if it is not? I had written some code for this and was surprised that it was never being called. If we are happy with this I'd like to commit this to CVS. Regards Vinay ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] ROWID Based Update: Load Entity Before Store Entity
Hello, Had sometime to review the rowid based update code and was wondering whether or not to do a code change for handling updates which happen in the same transaction as the insert. Here is what I found: 1. I have a Session Bean fronting an Entity Bean. The methods in the Session bean is have container transaction set to 'RequriesNew' and the methods in the Entity Bean have container transaction set to 'Requires' 2. The business method in the session bean creates an entity bean within the same method. So I'd assume the call to be like Call ---> [RequiresNew] Start Transaction --> Call create method on Entity Bean --> [Requires] Stick to current transaction --> Call set method on entity bean created --> [Requires] Stick to current transaction --> Commit 3. Alright, the way the methods are being called for different commit options are as [Default] --- Creating Call Now ---[Default] JDBCCommand Executing: SELECT COUNT(*) FROM itemizedcall WHERE accountnumber=? AND mobilenumber=? AND invoicenumber=? AND itemizedcallnumber=?[Default] JDBCCommand Executing: INSERT INTO itemizedcall (itemizedcallnumber,callcost,callduration,mobilenumber,accountnumber,invoicenumber,calltype) VALUES (?,?,?,?,?,?,?)[Default] --- Post Create for Entity Bean Now ---[Default] -- Load Entity -- [Default] -- Invoke Load -- [Default] --- Setting Call Cost Now ---[Default] -- Store Entity -- [Default] JDBCCommand Executing: UPDATE itemizedcall SET itemizedcallnumber=?,callcost=?,callduration=?,mobilenumber=?,accountnumber=?,invoicenumber=?,calltype=? WHERE ROWID =? This basically means that even within the same transaction the rowid will be updated if the client attempts to do an update [or delete]. Do we now need to check for rowid being null and falling back to the primary key if it is not? I had written some code for this and was surprised that it was never being called. If we are happy with this I'd like to commit this to CVS. Regards Vinay
Re: [JBoss-dev] Mail!
there you go! Vinay PS: Good to see you back on the list! - Original Message - From: "marc fleury" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "User @ JBoss" <[EMAIL PROTECTED]> Sent: Monday, June 11, 2001 2:14 AM Subject: RE: [JBoss-dev] Mail! > Just turn off the f***ing Html and you will see that it will work :) > > marc > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of K.V. > Vinay Menon > Sent: Monday, June 04, 2001 12:15 PM > To: User @ JBoss; Dev @ JBoss > Subject: [JBoss-dev] Mail! > > > Is it just me or is the mailiing list not working! Don't seem to get any > of my mails! [And yes, I have chosen to receive copies of my mails] > > Vinay > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Code: Stable RowID For Fast Updates
Hello Dan, Georg and all.
Here is the code update for the Fast RowID based
updates and deletes.
1. I have NOT modified the insert for insert into
as I am trying to avoid Oracle specified code [at least until JAWS becomes
completetly pluggable and all].
2. The only issue with this is that if the user
specified using the rowid and the rowid is null [say in ejbPostCreate, and when
else]. Given appropriate usage guidelines I think this can be
avoided.
3. I could have added code [in fact I did but
thought otherwise after that for defaulting back to the primary key IF the rowid
is null but that means we'd have to change the sql on the fly [ and during
setParameters since that is where the field values are actually read] which made
the code look rather clumsy.
To use this the user needs to specify the
stable-rowid-column value in the jaws.xml and a matching cmp field in the
bean.
Regards
Vinay
1. To the JawsEntityMetaData file
added
//Get
row id for fast stable row id based updates/deletes and inserts
stableRowIdColumn = getElementContent(getOptionalChild(element,
"stable-rowid-column"));
2. JDBCCreateEntityCommand.java
a) Constructor
/** * Don't include
the rowid column in the insert. That is something
the * database manages
for you.
*/
if(!cmpField.getColumnName().equalsIgnoreCase(rowIDColumn))
{
fieldSql += (first ? "" : ",")
+
cmpField.getColumnName();
valueSql += first ? "?" :
",?";
first = false; }b)
setParameters
/** * Don't use the
rowid column as that is something the
dbms * manages for
you.
*/
if(!cmpField.getColumnName().equalsIgnoreCase(rowIDColumn))
{
Object value = getCMPFieldValue(ctx.getInstance(),
cmpField);
setParameter(stmt, idx++, cmpField.getJDBCType(),
value);
}3.JDBCStoreEntityCommand
a) setParameters
String
stableRowIdColumn = jawsEntity.getStableRowIdColumn();
/** * Will store the actual value for
the stable row id column * and the JDBC
type for this column
*/ Object
stableRowIdColumnValue=null; int
stableRowIdColumnType=0;
while
(iter.hasNext())
{ CMPFieldMetaData cmpField
= (CMPFieldMetaData)iter.next();
/** * If the stable
row id column was specified in jaws.xml and the
current * column being
processed is the stable rowid coulmn, then save the
value * and datatype
as we will need it to set the parameters in the
WHERE *
clause
*/
if(stableRowIdColumn!=null &&
cmpField.getColumnName().equalsIgnoreCase(stableRowIdColumn))
{
stableRowIdColumnValue =
es.currentState[i];
stableRowIdColumnType =
cmpField.getJDBCType();
}
else
{ if
(!tuned ||
es.dirtyField[i])
{
setParameter(stmt, idx++, cmpField.getJDBCType(),
es.currentState[i]);
} }
i++; }
/** * Alright, we've set all the
parameters now and lets set the parameters
for * the WHERE clause. If the stable
row id was specified in the jaws.xml *
then set the parameter for that alone, else set the usual primary
key * parameters to update based on
that.
*/
if(stableRowIdColumn!=null)
{
setParameter(stmt,idx,stableRowIdColumnType,stableRowIdColumnValue);
} else
{
setPrimaryKeyParameters(stmt, idx,
es.ctx.getId()); }b) makeSQL
String
stableRowIdColumn =
jawsEntity.getStableRowIdColumn();
if(stableRowIdColumn==null)
{
/** * If it isn't there then
just set it to an empty string to avoid
checking * for null in a
loop.
*/ stableRowIdColumn =
""; }
String sql =
"UPDATE "+jawsEntity.getTableName()+" SET ";
Iterator iter = jawsEntity.getCMPFields(); int
i = 0; boolean first =
true; while
(iter.hasNext())
{ CMPFieldMetaData cmpField
= (CMPFieldMetaData)iter.next();
if(!(cmpField.getColumnName().equalsIgnoreCase(stableRowIdColumn) ||
cmpField.getName().equalsIgnoreCase(stableRowIdColumn)))
{ if
(!tuned ||
es.dirtyField[i++])
{
sql += (first?"":",")
+
cmpField.getColumnName() +
"=?";
first =
false;
}
} }
sql += " WHERE
";
//Construct the
WHERE clause - either based on the stable row id or the
PK if(stableRowIdColumn.trim().length()>1
&& (!overrideRowId))
{ sql +=
stableRowIdColumn+" =?";
} else
{ sql +=
getPkColumnWhereList(); }
4. JDBCRemoveEntityCommand
a) Constructor
Strin
Re: [JBoss-dev] Fast Updates Based on Row ID
The rowid will not be immediately available in the postcreate method. have not been able to simulate a condition where it will not be available when it will not be available apart from that which is why I do not really want to change insert statements etc. Vinay - Original Message - From: "Jay Walters" <[EMAIL PROTECTED]> To: "'K.V. Vinay Menon '" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Saturday, June 09, 2001 5:16 PM Subject: RE: [JBoss-dev] Fast Updates Based on Row ID > Why do you think the rowid won't be immediately available? > > -Original Message- > From: K.V. Vinay Menon > To: [EMAIL PROTECTED] > Sent: 6/9/01 11:47 AM > Subject: Re: [JBoss-dev] Fast Updates Based on Row ID > > Georg, Dan > > Alright. First of all do we really want to modify the insert sql to > return > the oracle rowid and hence end up putting oracle specific code. Believe > the > only issue we have is that given the fact that updates will be based on > the > row id and immediately after inserts the rowid would still be null we > might > end up with a few problems. Now, that is where I think we need to make > the > documentation work. If a person wishes to use rowid based updates etc > then > it must be clearly stated that the create method be defined in a > container > transaction that has value 'RequiresNew'. That way, the insert would be > committed immediately and even if the person did an update after the > insert > it would basically have the rowid value updated. I am just trying to > avoid > putting in code that is specific to any dbms - just require that a dbms > provide stable rowids. Do you see a problem with this? > > My views. Your thoughts? > > Vinay > - Original Message - > From: "Georg Rehfeld" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, June 09, 2001 5:40 AM > Subject: Re: [JBoss-dev] Fast Updates Based on Row ID > > > > Hi Dan and Vinay, > > > > > The reason I was suggesting an oracle specific option name was > because I > > > really think that we need to use the Oracle specific syntax to > return > > > the rowid value on inserts. > > > > Oops, I forgot about that. But Vinay is right, a stable ROWID > > might be present in several other databases already or in future. > > > > The 'insert ... select into' syntax today seems to be Oracle 8 > > specific (remember, Oracle 7 does not have it), but could make it > > into some standard? At least one and the other are not too closely > > related, this syntax especially can get back whatever you want > > from the just inserted row, not only the ROWID, but even some > > sequence value, some expression list to be more general. > > > > And other DB's having a stable ROWID ain't lost, as Vinay's code > > now falls back to the PK when a ROWID value isn't available. > > > > So I suggest 'stable-rowid-column' (including good docs) and > > a new tag 'insert-select-list' specifying a comma separated list > > of expressions to select from the inserted row and an appropriate > > number of placeholders for the result after a semicolon. > > (Or better, feel free to define the syntax, you got the idea). > > > > bye, my very best regards > > Georg > > ___ ___ > > | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg > > |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Fast Updates Based on Row ID
Georg, Dan Alright. First of all do we really want to modify the insert sql to return the oracle rowid and hence end up putting oracle specific code. Believe the only issue we have is that given the fact that updates will be based on the row id and immediately after inserts the rowid would still be null we might end up with a few problems. Now, that is where I think we need to make the documentation work. If a person wishes to use rowid based updates etc then it must be clearly stated that the create method be defined in a container transaction that has value 'RequiresNew'. That way, the insert would be committed immediately and even if the person did an update after the insert it would basically have the rowid value updated. I am just trying to avoid putting in code that is specific to any dbms - just require that a dbms provide stable rowids. Do you see a problem with this? My views. Your thoughts? Vinay - Original Message - From: "Georg Rehfeld" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 09, 2001 5:40 AM Subject: Re: [JBoss-dev] Fast Updates Based on Row ID > Hi Dan and Vinay, > > > The reason I was suggesting an oracle specific option name was because I > > really think that we need to use the Oracle specific syntax to return > > the rowid value on inserts. > > Oops, I forgot about that. But Vinay is right, a stable ROWID > might be present in several other databases already or in future. > > The 'insert ... select into' syntax today seems to be Oracle 8 > specific (remember, Oracle 7 does not have it), but could make it > into some standard? At least one and the other are not too closely > related, this syntax especially can get back whatever you want > from the just inserted row, not only the ROWID, but even some > sequence value, some expression list to be more general. > > And other DB's having a stable ROWID ain't lost, as Vinay's code > now falls back to the PK when a ROWID value isn't available. > > So I suggest 'stable-rowid-column' (including good docs) and > a new tag 'insert-select-list' specifying a comma separated list > of expressions to select from the inserted row and an appropriate > number of placeholders for the result after a semicolon. > (Or better, feel free to define the syntax, you got the idea). > > bye, my very best regards > Georg > ___ ___ > | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg > |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Option D in SynchronizationInterceptor
Hi, Why is the validContexts in the new option D enabled EntitySynchronizationInterceptor *NOT* synchrnoized. Will you really have a thread safe implementation in that case? I'd sent out an implementation of the soft ball cache refresh option sometime back [which I never got time to check in!!] and that was after finally persuading Marc that we had to synchronise the hashset. Also, a. the hashset is unique anyway why check for presence! b. there will be only one ctx per bean [correct me if i am wrong]. Also then we'd planned to have it as a separate class that could be fit into the inteceptor stack if required. Vinay Vinay
Re: [JBoss-dev] Fast Updates Based on Row ID
Have started looking at the code again, Do we want to specifically say 'oracle-tuned-updates'. What if actually proves useful for some other database - can't we just call it just 'rowid-column' and use the presence or absence of the tag to use rowid based updates? Vinay - Original Message - From: "danch" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 07, 2001 6:32 AM Subject: Re: [JBoss-dev] Fast Updates Based on Row ID > K.V. Vinay Menon wrote: > > > Dan Ch, > > Well as you might have noticed the code will work as usual if the > > rowid-column field is not specified in jaws.xml. If it is specified, it will > > then be used instead of the primary key. I am not sure of how other > > databases work with rowids which is why jaws will still default to normal > > behaviour. > > I think i'd rather have a flag on the JAWS entity to turn on > 'oracle-tuned-updates' than just indicating the name of the rowid > column. That way people will be less likely to turn it on for other > databases. > > > > Do you think we are in a position to submit the source? I'd have rather > > sent the modified source files for peer review in case I have goofed up! > > And *then* committed changes. Do you have the time to spare? > > I think we've gotten a pretty good peer review already. However, with > the insert issue and the change Georg points out later (detect empty > rowIDValue and fall back on primary key) I think you should probably > work those ideas into the code and post again. Are you on the JBossCMP > mailing list? Perhaps we should move this discussion there. > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Verifier Patch
Juha, For the verifier fix what on earth is the spec id .. 9..2.x.x? Any pointers would be much appreciated. Can check in the source once I get the correct value! Vinay
Re: [JBoss-dev] Fast Updates Based on Row ID
Will put in checks for null rowids. Need to figure out a way of changing the inserts as well. Will probably be only tomorrow though. Vinay - Original Message - From: "danch" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 07, 2001 6:32 AM Subject: Re: [JBoss-dev] Fast Updates Based on Row ID > K.V. Vinay Menon wrote: > > > Dan Ch, > > Well as you might have noticed the code will work as usual if the > > rowid-column field is not specified in jaws.xml. If it is specified, it will > > then be used instead of the primary key. I am not sure of how other > > databases work with rowids which is why jaws will still default to normal > > behaviour. > > I think i'd rather have a flag on the JAWS entity to turn on > 'oracle-tuned-updates' than just indicating the name of the rowid > column. That way people will be less likely to turn it on for other > databases. > > > > Do you think we are in a position to submit the source? I'd have rather > > sent the modified source files for peer review in case I have goofed up! > > And *then* committed changes. Do you have the time to spare? > > I think we've gotten a pretty good peer review already. However, with > the insert issue and the change Georg points out later (detect empty > rowIDValue and fall back on primary key) I think you should probably > work those ideas into the code and post again. Are you on the JBossCMP > mailing list? Perhaps we should move this discussion there. > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBOSS at JAVAONE
And is Marc is in his alien space suit?! Vinay - Original Message - From: "Bordet, Simone" <[EMAIL PROTECTED]> To: "JBoss Development Mailing List (E-mail)" <[EMAIL PROTECTED]> Sent: Wednesday, June 06, 2001 5:36 AM Subject: [JBoss-dev] JBOSS at JAVAONE > Hello everybody, > > JBoss *is* at JavaOne !!! > > We are hosted by the SAMS publishing in the JavaOne Pavillion. > > Marc is there all the mornings, I will be there very often, Rickard can be > often found there, as well as Scott Stark, Vaughn Vernon etc etc etc. > > And don't forget tomorrow's (wednesday) birds-of-a-feather (BOF-1097) at > 10:00 PM at the S. Francisco Marriot Hotel, Salon 14-15 !!! > > See you all ! > > Simon > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
Certification ceases to make any business sense when performance sucks! The customer is not bothered if you are running a J-2-E-E compliant / certified app server. They are not even bothered if you use Java or COBOL as long as they get what they want - a good user experience.At some point we have to come out of shells of java purism and get some business sense into things. Vinay - Original Message - From: "Jay Walters" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 06, 2001 4:55 PM Subject: RE: [JBoss-dev] Avoiding Locks for READ-ONLY Beans > I suppose it would get us out of the problem of being certified as J2EE > compliant as well... > > -Original Message- > From: K.V. Vinay Menon [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 06, 2001 11:46 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans > > > OK! > I know that it is kind of controversial and that its spec violation and > stuff but why can't we have multi threaded beans for read-only cases? Why > should we be bothered about transactions? We don't lock the database for > selects do we? Non-purists who face real world performance issues - please > let me know if these is complete rubbish or is something that 'could' prove > useful.. unless someone voluteers to write the code for multiple bean > instances per home handle! > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Fast Updates Based on Row ID
Dan Ch, Well as you might have noticed the code will work as usual if the rowid-column field is not specified in jaws.xml. If it is specified, it will then be used instead of the primary key. I am not sure of how other databases work with rowids which is why jaws will still default to normal behaviour. Do you think we are in a position to submit the source? I'd have rather sent the modified source files for peer review in case I have goofed up! And *then* committed changes. Do you have the time to spare? Regards, Vinay - Original Message - From: "danch (Dan Christopherson)" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 06, 2001 9:08 PM Subject: Re: [JBoss-dev] Fast Updates Based on Row ID > Just for the record, I don't mind having Oracle specific optimizations > in JAWS, it's just that the current structure of JAWS does not really > lend itself to this. Also, if you do use Oracle specific stuff for this > optimization, the option in a jaws entity should be given a name that > will tell users clearly that it won't work on other databases. > > K.V. Vinay Menon wrote: > > > Well, > > We are an Oracle shop and woudl benefit [like loads of other Oracle > > users] from these changes. Remember they are there as an option. If you > > choose not to use them JAWS will work as usual. > > > > Vinay > > - Original Message - > > From: "Jay Walters" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Wednesday, June 06, 2001 6:18 PM > > Subject: RE: [JBoss-dev] Fast Updates Based on Row ID > > > > > > > >>This is oracle specific as far as I know (insert...returning...). The > >>create problem needs to be addressed if one cannot retrieve the rowid, the > >>logic needs to check and see if rowid is set or not - maybe Vinay already > >>did this, I didn't look that hard. > >> > > > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans)
To be honest if the response time for a lookup is 5 seconds your clients
would go shopping elsewhere!
Vinay
- Original Message -
From: "danch (Dan Christopherson)" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 06, 2001 9:48 PM
Subject: Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for
READ-ONLY Beans)
> I don't understand what is different between the two. Are you saying to
> have only one place where we wait? If so I agree.
>
> 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 not locked loop again.
> >
> > OT, how does transaction timeout destroy the thread? TIA.
> >
> >
> > Bill
> >
> >
> >>-Original Message-
> >>From: [EMAIL PROTECTED]
> >>[mailto:[EMAIL PROTECTED]]On Behalf Of danch
> >>(Dan Christopherson)
> >>Sent: Wednesday, June 06, 2001 3:35 PM
> >>To: [EMAIL PROTECTED]
> >>Subject: Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for
> >>READ-ONLY Beans)
> >>
> >>
> >>I think that's roughly equivalent 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()) // pseudo code
> >>>{
> >>> this.wait(5000);
> >>> if (!locked())
> >>> {
> >>> log.("LOCKING-WAITING");
> >>> }
> >>>}
> >>>
> >>>
> >>>Regards,
> >>>Bill
> >>>
> >>>
> >>>
> >>>
> >>>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
danch
> (Dan Christopherson)
> Sent: Wednesday, June 06, 2001 1:31 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks
for
> READ-ONLY Beans)
>
>
> danch (Dan Christopherson) wrote:
>
>
>
> >Georg Rehfeld wrote:
> >
> >
> >
> >One problem here is that when we're waiting on the context, we want
to
> >wait on the context (i.e. "ctx.wait(DEADLOCKTIMEOUT + 1000)")
> >
> >
> Just doing
>
>
> >wait and notifyAll on the interceptor itself will involve all calls
on
> >our entity when we just want to handle contention for the one
context.
> >
> >The other problem is that if we're waiting on the transaction, we
don't
> >want to do wait/notify on the context - I don't know what we do want
to
> >wait on, but we really need to know when the transaction ends.
> >
> >
> Actually, looking closer at the code, it's probably the mutex that we
> want to wait on in both cases - it is specific to the key involved.
>
>
>
>
>
>
>
> >>>
> >>>
> >>>___
> >>>Jboss-development mailing list
> >>>[EMAIL PROTECTED]
> >>>http://lists.sourceforge.net/lists/listinfo/jboss-development
> >>>
> >>>
> >>
> >>
> >
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
>
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Fast Updates Based on Row ID
Jay, No. Not really. Its is just that the new Oracle release clearly state advantages of using rowids for updates and it is very attractive to have that kind of a facility for updates and deletes on huge tables [we do have quite a few tables that are in excess of 5-6 million records]. The idea is to have the option at hand so that it can be used as and when required [which is going to be quite a lot]. Issues like the client accessing the bean immediately after creation are things applications take care of by design - proper transactions and a decent session facade that ensures that screw ups don't happen. Regards, Vinay - Original Message - From: "Jay Walters" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 06, 2001 7:48 PM Subject: RE: [JBoss-dev] Fast Updates Based on Row ID > So do you build all your other applications to use rowid? > > -Original Message- > From: K.V. Vinay Menon [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 06, 2001 1:59 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Fast Updates Based on Row ID > > > Well, > We are an Oracle shop and woudl benefit [like loads of other Oracle > users] from these changes. Remember they are there as an option. If you > choose not to use them JAWS will work as usual. > > Vinay > - Original Message - > From: "Jay Walters" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, June 06, 2001 6:18 PM > Subject: RE: [JBoss-dev] Fast Updates Based on Row ID > > > > This is oracle specific as far as I know (insert...returning...). The > > create problem needs to be addressed if one cannot retrieve the rowid, the > > logic needs to check and see if rowid is set or not - maybe Vinay already > > did this, I didn't look that hard. > > > > It's not clear to me what this will do for us. It is likely the index > page > > will have been paged into the buffer cache to handle the initial query > which > > returned the row so I don't see this saving a lot of disk i/o, just some > cpu > > cycles. For example, depending on how one is creating the keys for new > rows > > a better improvement might be to embed oracle specific code into the > > creation to query a sequence for the key. If there is a goal to really > > speed up Jaws when using Oracle or some other database we should probably > > really analyze what it's doing, unless somebody is already doing that. > > > > Cheers > > > > -Original Message- > > From: danch (Dan Christopherson) [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, June 06, 2001 12:59 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] Fast Updates Based on Row ID > > > > > > Will the 'returning into ?' work in databases other than > > oracle? If not, that would be a problem: until JAWS is chainsawed > > (refactored to separate SQL syntax from the Command hierarchy), it'll be > > difficult to manage DB specific stuff at that level. Vinay's original > > patch isn't too bad, because it doesn't cause us to generate syntax that > > won't work elsewhere (you could give the name of a normal column as the > > rowid column and it would work (so long as that column is unique)) > > > > Jay Walters wrote: > > > > > Use "insert ... returning rowid into ?" > > > > > > -Original Message- > > > From: David Jencks [mailto:[EMAIL PROTECTED]] > > > Sent: Wednesday, June 06, 2001 12:02 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: [JBoss-dev] Fast Updates Based on Row ID > > > > > > > > > Hi, > > > > > > I may be wrong about oracle rowid changing on row update, it's been a > > > couple of years. However interbase/firebird dbkey definitely does > change > > > on update, and I think someone mentioned the sql server analogue does > too. > > > > > > In this situation, it seems to me that commit option A cannot be used, > > > since to get a valid rowid, you have to read the db within the same > > > transaction you are updating in. > > > > > > Also, even in Oracle, how can this be used with a newly inserted bean? > > > > > > create --inserts row in db > > > > > > later in same transaction, change values on this bean, the generated > save > > > has no rowid unless you fetched it in perhaps ejbpostcreate??? If you > can > > > fix this one, perhaps it can also be used to fetch values supplied by > > > triggers on insert, such as s
Re: [JBoss-dev] Fast Updates Based on Row ID
Ok,
I've changed the JDBCCreateEntityCommand as
public JDBCCreateEntityCommand(JDBCCommandFactory factory)
{
super(factory, "Create");
beanExistsCommand = factory.createBeanExistsCommand();
// Insert SQL
String sql = "INSERT INTO " + jawsEntity.getTableName();
String fieldSql = "";
String valueSql = "";
Iterator it = jawsEntity.getCMPFields();
boolean first = true;
//Added by Vinay - Start
String rowIDColumn = jawsEntity.getRowIDColumnName();
if(rowIDColumn==null) rowIDColumn = "";
while (it.hasNext())
{
CMPFieldMetaData cmpField = (CMPFieldMetaData)it.next();
if(!cmpField.getColumnName().equalsIgnoreCase(rowIDColumn))
{
fieldSql += (first ? "" : ",") +
cmpField.getColumnName();
valueSql += first ? "?" : ",?";
first = false;
}
}
sql += " ("+fieldSql+") VALUES ("+valueSql+")";
setSQL(sql);
}
and
protected void setParameters(PreparedStatement stmt, Object argOrArgs)
throws Exception
{
EntityEnterpriseContext ctx = (EntityEnterpriseContext)argOrArgs;
int idx = 1; // Parameter-index
Iterator iter = jawsEntity.getCMPFields();
String rowIDColumn = jawsEntity.getRowIDColumnName();
if(rowIDColumn==null) rowIDColumn = "";
while (iter.hasNext())
{
CMPFieldMetaData cmpField = (CMPFieldMetaData)iter.next();
if(!cmpField.getColumnName().equalsIgnoreCase(rowIDColumn))
{
Object value = getCMPFieldValue(ctx.getInstance(), cmpField);
setParameter(stmt, idx++, cmpField.getJDBCType(), value);
}
}
}
Now in my client code I have done something like
cl.addItemizedCall(callItem); //does the insert
calls =
cl.getAllItemizedCalls("99","07947018717","5050505050");
I *DO* get the row ID. I believe some things have changed in
Oracle 817 and perhaps this is one of them but I do get the ROWID
automatically without *any* additional code in the ejbPostCreate Method.
Vinay
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
Very true! I could do that. That way folks who want to use it can use it. Vinay - Original Message - From: "danch (Dan Christopherson)" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 06, 2001 5:37 PM Subject: Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans > It may well be usefull, but does this behavior belong in the normal > EntityInstanceInterceptor? Why not just implement an non-blocking > variant of EntityInstanceInterceptor, and reconfigure your stack in > jboss.xml? > > K.V. Vinay Menon wrote: > > > OK! > > I know that it is kind of controversial and that its spec violation and > > stuff but why can't we have multi threaded beans for read-only cases? Why > > should we be bothered about transactions? We don't lock the database for > > selects do we? Non-purists who face real world performance issues - please > > let me know if these is complete rubbish or is something that 'could' prove > > useful.. unless someone voluteers to write the code for multiple bean > > instances per home handle! > > > > > > Vinay > > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Fast Updates Based on Row ID
Sorry, I stand corrected the rowid will not be updated automatically.
- Original Message -
From: "K.V. Vinay Menon" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 06, 2001 6:56 PM
Subject: Re: [JBoss-dev] Fast Updates Based on Row ID
> Ok,
> I've changed the JDBCCreateEntityCommand as
>
>public JDBCCreateEntityCommand(JDBCCommandFactory factory)
>{
> super(factory, "Create");
>
> beanExistsCommand = factory.createBeanExistsCommand();
>
> // Insert SQL
>
> String sql = "INSERT INTO " + jawsEntity.getTableName();
> String fieldSql = "";
> String valueSql = "";
>
> Iterator it = jawsEntity.getCMPFields();
> boolean first = true;
>
> //Added by Vinay - Start
> String rowIDColumn = jawsEntity.getRowIDColumnName();
> if(rowIDColumn==null) rowIDColumn = "";
>
>
> while (it.hasNext())
> {
> CMPFieldMetaData cmpField = (CMPFieldMetaData)it.next();
>
> if(!cmpField.getColumnName().equalsIgnoreCase(rowIDColumn))
> {
> fieldSql += (first ? "" : ",") +
> cmpField.getColumnName();
> valueSql += first ? "?" : ",?";
> first = false;
> }
> }
>
> sql += " ("+fieldSql+") VALUES ("+valueSql+")";
>
> setSQL(sql);
>}
>
>
> and
>
>protected void setParameters(PreparedStatement stmt, Object argOrArgs)
> throws Exception
>{
> EntityEnterpriseContext ctx = (EntityEnterpriseContext)argOrArgs;
> int idx = 1; // Parameter-index
>
> Iterator iter = jawsEntity.getCMPFields();
>
> String rowIDColumn = jawsEntity.getRowIDColumnName();
> if(rowIDColumn==null) rowIDColumn = "";
>
>
>
> while (iter.hasNext())
> {
> CMPFieldMetaData cmpField = (CMPFieldMetaData)iter.next();
>
> if(!cmpField.getColumnName().equalsIgnoreCase(rowIDColumn))
> {
> Object value = getCMPFieldValue(ctx.getInstance(), cmpField);
> setParameter(stmt, idx++, cmpField.getJDBCType(), value);
> }
> }
>}
>
>Now in my client code I have done something like
>
> cl.addItemizedCall(callItem); //does the insert
> calls =
> cl.getAllItemizedCalls("99","07947018717","5050505050");
>
> I *DO* get the row ID. I believe some things have changed
in
> Oracle 817 and perhaps this is one of them but I do get the ROWID
> automatically without *any* additional code in the ejbPostCreate Method.
>
> Vinay
>
>
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Fast Updates Based on Row ID
Ok, Back to the row id issue, what if I just set the create method's transaction demaraction as 'RequiresNew'. That way all inserts will get commited immediately. Any succeeding requests from the same client would be on a different transaction and hence the rowid would not be returned as null. What do you think? Vinay - Original Message - From: "danch (Dan Christopherson)" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 06, 2001 5:58 PM Subject: Re: [JBoss-dev] Fast Updates Based on Row ID > Will the 'returning into ?' work in databases other than > oracle? If not, that would be a problem: until JAWS is chainsawed > (refactored to separate SQL syntax from the Command hierarchy), it'll be > difficult to manage DB specific stuff at that level. Vinay's original > patch isn't too bad, because it doesn't cause us to generate syntax that > won't work elsewhere (you could give the name of a normal column as the > rowid column and it would work (so long as that column is unique)) > > Jay Walters wrote: > > > Use "insert ... returning rowid into ?" > > > > -Original Message- > > From: David Jencks [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, June 06, 2001 12:02 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] Fast Updates Based on Row ID > > > > > > Hi, > > > > I may be wrong about oracle rowid changing on row update, it's been a > > couple of years. However interbase/firebird dbkey definitely does change > > on update, and I think someone mentioned the sql server analogue does too. > > > > In this situation, it seems to me that commit option A cannot be used, > > since to get a valid rowid, you have to read the db within the same > > transaction you are updating in. > > > > Also, even in Oracle, how can this be used with a newly inserted bean? > > > > create --inserts row in db > > > > later in same transaction, change values on this bean, the generated save > > has no rowid unless you fetched it in perhaps ejbpostcreate??? If you can > > fix this one, perhaps it can also be used to fetch values supplied by > > triggers on insert, such as sequence/generators used for abstract id. > > > > Am I wrong here? Could you explain in detail how this will work? > > > > Thanks > > david jencks > > > > On 2001.06.06 10:50:53 -0400 K.V. Vinay Menon wrote: > > > >>The ROW ID bit does not touch ANY other portion in the JBoss source > >>except > >>for > >> > >>a) Generating SQLs > >>b) Setting parameters. > >> > >>Options A,B and C should work as usual, correct me if I am wrong. As for > >>option D, I am suprised that it has become part of our 'standard' commit > >>options. I wrote some code and never had a chance to commit it and unless > >>someone else has commited stuff for option D let me know and I'll have to > >>commit the code! > >> > >>Vinay > >>- Original Message - > >>From: "David Jencks" <[EMAIL PROTECTED]> > >>To: <[EMAIL PROTECTED]> > >>Sent: Wednesday, June 06, 2001 2:40 PM > >>Subject: Re: [JBoss-dev] Fast Updates Based on Row ID > >> > >> > >> > >>>Hi, > >>> > >>>This looks very interesting. I'm kind of too lazy to read your code to > >>>find out the answer for myself... > >>> > >>>My impression is that Oracle ROWID and similar facilities such as > >>>Interbase/firebird dbkey are stable only within a transaction, and in > >>> > >>fact > >> > >>>expected to change with any update. Could you please explain how your > >>> > >>new > >> > >>>feature guarantees updating the correct row with commit options A, B, > >>> > >>C, > >> > >>>and D? > >>> > >>>Thanks > >>>david jencks > >>> > >>> > >>>On 2001.06.06 08:56:02 -0400 K.V. Vinay Menon wrote: > >>> > >>>>Hi Marc, > >>>>When you were here in London we'd discussed adding functionality > >>>> > >>to > >> > >>>>use things like ROWID for fast updates and deletes [as opposed to > >>>> > >>using > >> > >>>>primary keys]. I have been able to implement this by > >>>> > >>>>1. Adding a field in
Re: [JBoss-dev] Fast Updates Based on Row ID
Well, We are an Oracle shop and woudl benefit [like loads of other Oracle users] from these changes. Remember they are there as an option. If you choose not to use them JAWS will work as usual. Vinay - Original Message - From: "Jay Walters" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 06, 2001 6:18 PM Subject: RE: [JBoss-dev] Fast Updates Based on Row ID > This is oracle specific as far as I know (insert...returning...). The > create problem needs to be addressed if one cannot retrieve the rowid, the > logic needs to check and see if rowid is set or not - maybe Vinay already > did this, I didn't look that hard. > > It's not clear to me what this will do for us. It is likely the index page > will have been paged into the buffer cache to handle the initial query which > returned the row so I don't see this saving a lot of disk i/o, just some cpu > cycles. For example, depending on how one is creating the keys for new rows > a better improvement might be to embed oracle specific code into the > creation to query a sequence for the key. If there is a goal to really > speed up Jaws when using Oracle or some other database we should probably > really analyze what it's doing, unless somebody is already doing that. > > Cheers > > -Original Message- > From: danch (Dan Christopherson) [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 06, 2001 12:59 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Fast Updates Based on Row ID > > > Will the 'returning into ?' work in databases other than > oracle? If not, that would be a problem: until JAWS is chainsawed > (refactored to separate SQL syntax from the Command hierarchy), it'll be > difficult to manage DB specific stuff at that level. Vinay's original > patch isn't too bad, because it doesn't cause us to generate syntax that > won't work elsewhere (you could give the name of a normal column as the > rowid column and it would work (so long as that column is unique)) > > Jay Walters wrote: > > > Use "insert ... returning rowid into ?" > > > > -Original Message- > > From: David Jencks [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, June 06, 2001 12:02 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] Fast Updates Based on Row ID > > > > > > Hi, > > > > I may be wrong about oracle rowid changing on row update, it's been a > > couple of years. However interbase/firebird dbkey definitely does change > > on update, and I think someone mentioned the sql server analogue does too. > > > > In this situation, it seems to me that commit option A cannot be used, > > since to get a valid rowid, you have to read the db within the same > > transaction you are updating in. > > > > Also, even in Oracle, how can this be used with a newly inserted bean? > > > > create --inserts row in db > > > > later in same transaction, change values on this bean, the generated save > > has no rowid unless you fetched it in perhaps ejbpostcreate??? If you can > > fix this one, perhaps it can also be used to fetch values supplied by > > triggers on insert, such as sequence/generators used for abstract id. > > > > Am I wrong here? Could you explain in detail how this will work? > > > > Thanks > > david jencks > > > > On 2001.06.06 10:50:53 -0400 K.V. Vinay Menon wrote: > > > >>The ROW ID bit does not touch ANY other portion in the JBoss source > >>except > >>for > >> > >>a) Generating SQLs > >>b) Setting parameters. > >> > >>Options A,B and C should work as usual, correct me if I am wrong. As for > >>option D, I am suprised that it has become part of our 'standard' commit > >>options. I wrote some code and never had a chance to commit it and unless > >>someone else has commited stuff for option D let me know and I'll have to > >>commit the code! > >> > >>Vinay > >>- Original Message - > >>From: "David Jencks" <[EMAIL PROTECTED]> > >>To: <[EMAIL PROTECTED]> > >>Sent: Wednesday, June 06, 2001 2:40 PM > >>Subject: Re: [JBoss-dev] Fast Updates Based on Row ID > >> > >> > >> > >>>Hi, > >>> > >>>This looks very interesting. I'm kind of too lazy to read your code to > >>>find out the answer for myself... > >>> > >>>My impression is that Oracle ROWID and similar facilities such as > >>>Interbase/firebird dbkey are stable
Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
OK!
I know that it is kind of controversial and that its spec violation and
stuff but why can't we have multi threaded beans for read-only cases? Why
should we be bothered about transactions? We don't lock the database for
selects do we? Non-purists who face real world performance issues - please
let me know if these is complete rubbish or is something that 'could' prove
useful.. unless someone voluteers to write the code for multiple bean
instances per home handle!
Vinay
- Original Message -
From: "Georg Rehfeld" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 06, 2001 1:35 PM
Subject: Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
> Hi Vinay,
>
> see below
>
> > In order to avoid locking for TX or CTX in the
> > EntityInstanceInterceptor, I've basically added a flag to
> > indicate whether the bean can be optimized for read only
> > operation. In the EntityInstanceInterceptor, where the loop
> > actually wait for the lock I've added a condition
> >
> > isReadOptimized = metadata.isReadOptimized();
> >
> > if(!isReadOptimized)
> > {
> > ...
> > ...
> > go about as usual trying to aquire lock etc
> > }
> >
> > mi.setEnterpriseContext(ctx);
> > return getNext().invoke(mi);
> >
> > and in the finally clause
> >
> > if (ctx != null && (!isReadOptimized))
> > {
> > //business as usual code
> > }
> >
> > What is good is that I no longer have my response times creeping
> > up under sustained loads. Does this look alright? Does anyone
> > anticipate any other problems due to this. Would really
> > appreciate if folks who really have the 'bigger picture' can let
> > me know.
>
> Might be better you provide a context diff to us, so we more
> exactly can see what you plan to do (change code, do
> cvs diff -u EntityInstanceInterceptor.java).
>
> As far as I understand, you skip the whole
> do { ... } while (ctx == null); loop? So you end up with a null
> EnterpriseContext, not a good idea IMHO, because i.e. security
> and transactional settings (amoung other important things) are
> attached to it, most likely invoked other interceptors rely on
> the ctx set?!
>
> Where does your isReadOptimized come from, JAWS? If so, the BMP
> developers are left alone.
>
> I still would insist on the correction of the missing wait/notify
> issue, as I still believe that the extremly bad response times
> under load are more caused by several threads executing tight
> loops consuming most of the cpu time instead of simply waiting
> and let the cpu to JBoss doing real work!
>
> I'm NOT a multithreading expert though. My first thought was to
> simply insert a wait() directly after the two
> Logger.debug("LOCKING-WAITING ..."); calls and a notifyAll()
> after the ctx.unlock() in the finally clause, but I've 2 problems
> with this approach:
>
> 1. there is a mutex.aquire()/mutex.release() pair; when I simply
> would wait inbetween, I think no other thread can enter the code
> thus rendering EntityInstanceInterceptor dead, when one thread is
> waiting, on the other hand, I can't simply release the mutex
> there, it's a critical section. A solution would be to have a
> wait directly before the } while (ctx == null); if ctx == 0 as of
> this (hand made) context diff:
>
> catch (InterruptedException ignored) {}
> finally
> {
> mutex.release();
> }
> + if (ctx == null) {
> + // let the thread that has the lock proceed
> + // at same time let's detect possible deadlock
> + long start = System.getCurrentTimeMillis();
> + try {
> + wait(DEADLOCKTIMEOUT + 1000);
> + }
> + catch (InterruptedException ignored) {}
> + finally {
> + if (System.getCurrentTimeMillis() - start
> + > DEADLOCKTIMEOUT)
> + {
> + throw new EJBException(
> + "possible deadlock detected");
> + }
> + }
> + }
> } while (ctx == null);
> ...
> ...
> else
> {
> // Yeah, do nothing
> }
> + notifyAll();
> }
> catch (InterruptedException ignored) {}
> finally
> {
> mutex.release();
> }
>
> 2. the notifyAll() above better should not awake any thread in
> JBoss, but better only the threads that wait above, hmmm, isn't
> this implicit? Do we need thread groups? It would be
> best/required that the Interceptor only waits, when the same bean
> instance is to be entered concurrently (this should be so
> already) and that only exactly the threads, t
Re: [JBoss-dev] Fast Updates Based on Row ID
Locks will be in place since the rowid stuff is applicable only for updates and deletes. selects obviously cannot work with this! Also, to the best of my knowledge Oracle row ids are fixed unless you move them to new db i.e. export or stuff. Vinay - Original Message - From: "Georg Rehfeld" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 06, 2001 2:57 PM Subject: Re: [JBoss-dev] Fast Updates Based on Row ID > Hi Vinay, > > as far as I can remember from my Oracle times using the ROWID is > only allowed inside transactions and when you got the row with > SELECT ... FOR UPDATE else the ROWID isn't fixed, but may change, > when other clients update the row (at least when the update > causes the row to be moved to another block in the DB, as the > ROWID in Oracle is the physical address of the row). > > I havn't the docs handy, if you have them online, then you might > search for ROWID until you find that precondition, sorry, but I'm > pretty sure it exists. > > In your code I couldn't find checks for either, at least the > JAWS option should be available and checked > for true, migth be this is enough checking there, as select for > update is valid inside transactions only anyway. > > regards > Georg > ___ ___ > | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg > |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Fast Updates Based on Row ID
The ROW ID bit does not touch ANY other portion in the JBoss source except for a) Generating SQLs b) Setting parameters. Options A,B and C should work as usual, correct me if I am wrong. As for option D, I am suprised that it has become part of our 'standard' commit options. I wrote some code and never had a chance to commit it and unless someone else has commited stuff for option D let me know and I'll have to commit the code! Vinay - Original Message - From: "David Jencks" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 06, 2001 2:40 PM Subject: Re: [JBoss-dev] Fast Updates Based on Row ID > Hi, > > This looks very interesting. I'm kind of too lazy to read your code to > find out the answer for myself... > > My impression is that Oracle ROWID and similar facilities such as > Interbase/firebird dbkey are stable only within a transaction, and in fact > expected to change with any update. Could you please explain how your new > feature guarantees updating the correct row with commit options A, B, C, > and D? > > Thanks > david jencks > > > On 2001.06.06 08:56:02 -0400 K.V. Vinay Menon wrote: > > Hi Marc, > > When you were here in London we'd discussed adding functionality to > > use things like ROWID for fast updates and deletes [as opposed to using > > primary keys]. I have been able to implement this by > > > > 1. Adding a field in jaws.xml called rowid-column name. This is ROWID for > > Oracle and can be something else for other databases. If you do not want > > to use this feature just don't specify the tag and it will use the > > default mechansm based on the primary key. > > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Fw: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java JDBCLoadEntityCommand.java
Phew! I spent a couple of hours trying to figure out what problem was because I was doing the ROWID bit and was wondering where on earth the values were getting mixed up!!! Vinay - Original Message - From: "danch" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 06, 2001 6:14 PM Subject: Re: Fw: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java JDBCLoadEntityCommand.java > K.V. Vinay Menon wrote: > > > Dan Ch, > > Was this part of the 2.2.2 release. I actually had issues with the load > > [it was screwing up the columns] because their order in the resultset and in > > the iterator for getCMPFields was different. Actually got all that to work > > when I saw this update from you! Anyway, just wanted to confirm that this > > issue is NOT there in the standard 2.2.2 release. > > No it was not in 2.2.2. > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Fast Updates Based on Row ID
Dan Ch,
Have not submitted the patch as yet. I'll check it in once people think
its alright. Do you want me to send you complete source files for the
changes?
Vinay
- Original Message -
From: "danch" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 06, 2001 6:17 PM
Subject: Re: [JBoss-dev] Fast Updates Based on Row ID
> I'll get this patch in later today.
>
> K.V. Vinay Menon wrote:
>
> > Hi Marc,
> >
> > When you were here in London we'd discussed adding functionality to
> > use things like ROWID for fast updates and deletes [as opposed to using
> > primary keys]. I have been able to implement this by
> >
> >
> >
> > 1. Adding a field in jaws.xml called rowid-column name. This is ROWID
> > for Oracle and can be something else for other databases. If you do not
> > want to use this feature just don't specify the tag and it will use the
> > default mechansm based on the primary key.
> >
> >
> >
> > 2. Updated JDBCStoreEntityCommand as follows
> >
> >
> >
> >protected String makeSQL(Object argOrArgs)
> >{
> > ExecutionState es = (ExecutionState)argOrArgs; // NB: null if
tuned
> > boolean tuned = jawsEntity.hasTunedUpdates();
> >
> >
> >
> > //Added by Vinay Menon - Start
> > String rowIDColumn = jawsEntity.getRowIDColumnName();
> > //Added by Vinay Menon - End
> >
> >
> >
> > String sql = "UPDATE "+jawsEntity.getTableName()+" SET ";
> > Iterator iter = jawsEntity.getCMPFields();
> > int i = 0;
> > boolean first = true;
> > while (iter.hasNext())
> > {
> > CMPFieldMetaData cmpField = (CMPFieldMetaData)iter.next();
> >
> >
> >
> > if(!cmpField.getColumnName().equalsIgnoreCase(rowIDColumn))
> > {
> > if (!tuned || es.dirtyField[i++])
> > {
> > sql += (first?"":",") +
> >cmpField.getColumnName() + "=?";
> > first = false;
> > }
> > }
> > }
> >
> >
> >
> > //Modified by Vinay Menon - Start
> > sql += " WHERE ";
> >
> >
> >
> > if(rowIDColumn!=null && rowIDColumn.trim().length()>1)
> > {
> > sql += rowIDColumn+" =?";
> > }
> > else
> > {
> > sql += getPkColumnWhereList();
> > }
> > //Modified by Vinay Menon - End
> >
> >
> >
> > return sql;
> >}
> >
> > and
> >
> >
> >
> >protected void setParameters(PreparedStatement stmt, Object
argOrArgs)
> > throws Exception
> >{
> > ExecutionState es = (ExecutionState)argOrArgs;
> > boolean tuned = jawsEntity.hasTunedUpdates();
> >
> >
> >
> > //Added by Vinay Menon - Start
> > String rowIDColumn = jawsEntity.getRowIDColumnName();
> > //Added by Vinay Menon - End
> >
> >
> >
> > int idx = 1;
> > Iterator iter = jawsEntity.getCMPFields();
> > int i = 0;
> >
> >
> >
> > Object rowIDValue=null;
> > int rowIDJDBCType=0;
> >
> >
> >
> > while (iter.hasNext())
> > {
> > CMPFieldMetaData cmpField = (CMPFieldMetaData)iter.next();
> >
> >
> >
> >
> > f((!cmpField.getColumnName().equalsIgnoreCase(rowIDColumn)) &&
> > (!cmpField.getName().equalsIgnoreCase(rowIDColumn)))
> > {
> > rowIDValue = es.currentState[i];
> > rowIDJDBCType = cmpField.getJDBCType();
> > } else {
> > if (!tuned || es.dirtyField[i])
> > {
> > setParameter(stmt, idx++, cmpField.getJDBCType(),
> > es.currentState[i]);
> > }
> > }
> >
> >
> >
> > i++;
> > }
> >
> >
> >
> > if(rowIDColumn!=null)
> > {
> > setParameter(stmt,idx,rowIDJDBCType,rowIDValue);
> > }
> > else
> > {
> > setPrimaryKeyParameters(stmt, idx, es.ctx.getId());
> > }
> > //Modified by Vinay Menon - End
> >}
> >
> > 3. Similarly updated JDBCRemoveEntityCom
[JBoss-dev] Fast Updates Based on Row ID
Hi Marc,
When you were here in London
we'd discussed adding functionality to use things like ROWID for fast updates
and deletes [as opposed to using primary keys]. I have been able to implement
this by
1. Adding a field in jaws.xml called rowid-column
name. This is ROWID for Oracle and can be something else for other databases. If
you do not want to use this feature just don't specify the tag and it will use
the default mechansm based on the primary key.
2. Updated JDBCStoreEntityCommand as
follows
protected String makeSQL(Object
argOrArgs) { ExecutionState es
= (ExecutionState)argOrArgs; // NB: null if
tuned boolean tuned =
jawsEntity.hasTunedUpdates();
//Added by Vinay
Menon - Start String rowIDColumn =
jawsEntity.getRowIDColumnName(); //Added by
Vinay Menon - End
String sql =
"UPDATE "+jawsEntity.getTableName()+" SET ";
Iterator iter = jawsEntity.getCMPFields(); int
i = 0; boolean first =
true; while
(iter.hasNext())
{ CMPFieldMetaData cmpField
= (CMPFieldMetaData)iter.next();
if(!cmpField.getColumnName().equalsIgnoreCase(rowIDColumn))
{ if
(!tuned ||
es.dirtyField[i++])
{
sql += (first?"":",")
+
cmpField.getColumnName() +
"=?";
first =
false;
}
} }
//Modified by Vinay
Menon - Start sql += " WHERE
";
if(rowIDColumn!=null &&
rowIDColumn.trim().length()>1)
{ sql += rowIDColumn+"
=?"; }
else
{ sql +=
getPkColumnWhereList();
} //Modified by Vinay Menon -
End
return
sql; }
and
protected void
setParameters(PreparedStatement stmt, Object
argOrArgs) throws Exception
{ ExecutionState es =
(ExecutionState)argOrArgs; boolean tuned =
jawsEntity.hasTunedUpdates();
//Added by Vinay
Menon - Start String rowIDColumn =
jawsEntity.getRowIDColumnName(); //Added by
Vinay Menon - End
int idx =
1; Iterator iter =
jawsEntity.getCMPFields(); int i =
0;
Object
rowIDValue=null; int
rowIDJDBCType=0;
while
(iter.hasNext())
{ CMPFieldMetaData cmpField
= (CMPFieldMetaData)iter.next();
f((!cmpField.getColumnName().equalsIgnoreCase(rowIDColumn)) &&
(!cmpField.getName().equalsIgnoreCase(rowIDColumn)))
{
rowIDValue =
es.currentState[i];
rowIDJDBCType =
cmpField.getJDBCType(); }
else
{ if
(!tuned ||
es.dirtyField[i])
{
setParameter(stmt, idx++, cmpField.getJDBCType(),
es.currentState[i]);
} }
i++; }
if(rowIDColumn!=null)
{
setParameter(stmt,idx,rowIDJDBCType,rowIDValue);
} else
{
setPrimaryKeyParameters(stmt, idx,
es.ctx.getId());
} //Modified by Vinay Menon -
End }
3. Similarly updated JDBCRemoveEntityCommand as
protected void
setParameters(PreparedStatement stmt, Object
argOrArgs) throws Exception
{ EntityEnterpriseContext ctx =
(EntityEnterpriseContext)argOrArgs;
ExecutionState es =
(ExecutionState)argOrArgs;
//Modified by Vinay
Menon - Start String rowIDColumn =
jawsEntity.getRowIDColumnName(); int
i=0;
if(rowIDColumn!=null)
{ Iterator iter =
jawsEntity.getCMPFields();
while (iter.hasNext())
{
CMPFieldMetaData cmpField = (CMPFieldMetaData)iter.next();
if(cmpField.getColumnName().equalsIgnoreCase(rowIDColumn))
{
System.out.println("Delete for
"+rowIDColumn+"="+es.currentState[i]);
setParameter(stmt, 1, cmpField.getJDBCType(),
es.currentState[i]);
}
i++;
} }
else
{ setPrimaryKeyParameters(stmt, 1,
ctx.getId());
} //Modified by Vinay Menon -
Start }
and
public
JDBCRemoveEntityCommand(JDBCCommandFactory factory)
{ super(factory, "Remove");
//Modified by
Vinay Menon - Start String rowIDColumn =
jawsEntity.getRowIDColumnName();
String
sql;
if(rowIDColumn!=null)
{ // Remove
SQL sql = "DELETE FROM
" + jawsEntity.getTableName() +" WHERE
"+rowIDColumn+"=?";
} else
{ // Remove
SQL sql = "DELETE FROM
" + jawsEntity.getTableName()
+
" WHERE "+getPkColumnWhereList();
} //Modified by Vinay Menon -
End
setSQL(sql); }
3. Updated JawsEntityMetaData with
public String
getRowIDColumnName() { return rowIDColumnName; }
Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
My view is if the new option to have multiple bean instances is going to
take long to write why should we be bothered about concurrency in a read
only bean?
Vinay
- Original Message -
From: "Dan OConnor" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 06, 2001 1:26 PM
Subject: Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
> Hi,
>
> First of all, thanks for the contribution. Things get done when
> people jump in and contribute their time, and we definitely have a
> scaling problem we need to fix.
>
> If I understand the implications of your code, I'm very against this
> particular solution, as it is a violation of the EJB spec and will also
> create concurrency problems unless the EJB component is also
> written in violation of the spec. (This is nothing against you; this
> approach has been suggested before.)
>
> Bottom line: if I'm correct that this allows multi-threaded access to
> a single entity instance, I think you should take it out. The correct
> solution to the locking problem as I see it is slightly more work:
> add support for multiple instances of entities associated with the
> same primary key for commit option "C". See my previous post.
>
> Of course, others may disagree, so this is just my opinion. I hope
> Marc, Juha, Simone, Rickard, etc. will offer their opinions, as this
> is a pretty key piece of code. Maybe they can talk about it at Java
> One. :-)
>
> I might be wrong about what is going on, or about the ultimate
> utility of this piece of code. But it is a key piece of code for the
> container, and needs to be reviewed carefully.
>
> -Dan
>
> On 6 Jun 01, at 9:32, K.V. Vinay Menon wrote:
>
> > Hello,
> >
> > In order to avoid locking for TX or CTX in the
EntityInstanceInterceptor, I've basically added a flag to indicate whether
the bean can be optimized for read only operation. In the
EntityInstanceInterceptor, where the loop actually wait for the lock I've
added a condition
> >
> > isReadOptimized = metadata.isReadOptimized();
> >
> > if(!isReadOptimized)
> > {
> > ...
> > ...
> > go about as usual trying to aquire lock etc
> > }
> >
> > mi.setEnterpriseContext(ctx);
> > return getNext().invoke(mi);
> >
> > and in the finally clause
> >
> > if (ctx != null && (!isReadOptimized))
> > {
> > //business as usual code
> > }
> >
> > What is good is that I no longer have my response times
creeping up under sustained
> loads.
> >Does this look alright? Does anyone anticipate any other
problems due to this. Wou
> ld really appreciate if folks who really have the 'bigger picture' can let
me know.
> >
> > Thanks
> >
> > Vinay
> >
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Fw: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java JDBCLoadEntityCommand.java
Dan Ch,
Was this part of the 2.2.2 release. I actually had issues with the load
[it was screwing up the columns] because their order in the resultset and in
the iterator for getCMPFields was different. Actually got all that to work
when I saw this update from you! Anyway, just wanted to confirm that this
issue is NOT there in the standard 2.2.2 release.
Vinay
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 06, 2001 2:07 AM
Subject: [JBoss-dev] CVS update:
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java
JDBCLoadEntityCommand.java
> User: danch
> Date: 01/06/05 18:07:40
>
> Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java
> JDBCLoadEntityCommand.java
> Log:
> Fixed bug caused by change in load operation associated with finder
optimization.
>
> Revision ChangesPath
> 1.32 +4 -3
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommand.java
>
> Index: JDBCCommand.java
> ===
> RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommand.ja
va,v
> retrieving revision 1.31
> retrieving revision 1.32
> diff -u -r1.31 -r1.32
> --- JDBCCommand.java 2001/05/30 23:00:42 1.31
> +++ JDBCCommand.java 2001/06/06 01:07:40 1.32
> @@ -57,7 +57,7 @@
> *
> * @author mailto:[EMAIL PROTECTED]";>Justin Forder
> * @author mailto:[EMAIL PROTECTED]";>Dirk Zimmermann
> - * @version $Revision: 1.31 $
> + * @version $Revision: 1.32 $
> */
>public abstract class JDBCCommand
>{
> @@ -386,6 +386,7 @@
>protected Object getResultObject(ResultSet rs, int idx, Class
destination)
>throws SQLException{
>
> +log.debug("getting a "+destination.getName()+" from resultset at index
"+idx);
>Object result = null;
>
>Method method = (Method)rsTypes.get(destination.getName());
> @@ -484,9 +485,9 @@
>} catch (RemoteException e) {
>throw new SQLException("Unable to load EJBObject back from Handle: "
+e);
>} catch (IOException e) {
> -throw new SQLException("Unable to load a ResultSet
column into a variable of type '"+destination.getName()+"': "+e);
> +throw new SQLException("Unable to load a ResultSet
column "+idx+" into a variable of type '"+destination.getName()+"': "+e);
>} catch (ClassNotFoundException e) {
> -throw new SQLException("Unable to load a ResultSet
column into a variable of type '"+destination.getName()+"': "+e);
> +throw new SQLException("Unable to load a ResultSet
column "+idx+" into a variable of type '"+destination.getName()+"': "+e);
>}
>}
>
>
>
>
> 1.10 +55 -10
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCLoadEntityCommand.java
>
> Index: JDBCLoadEntityCommand.java
> ===
> RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCLoadEntity
Command.java,v
> retrieving revision 1.9
> retrieving revision 1.10
> diff -u -r1.9 -r1.10
> --- JDBCLoadEntityCommand.java 2001/05/27 00:49:15 1.9
> +++ JDBCLoadEntityCommand.java 2001/06/06 01:07:40 1.10
> @@ -11,6 +11,8 @@
>import java.lang.reflect.Method;
>
>import java.util.Iterator;
> +import java.util.ArrayList;
> +import java.util.List;
>import java.util.HashMap;
>
>import java.rmi.NoSuchObjectException;
> @@ -36,12 +38,28 @@
> * @author mailto:[EMAIL PROTECTED]";>Joe Shevland
> * @author mailto:[EMAIL PROTECTED]";>Justin Forder
> * @author mailto:[EMAIL PROTECTED]";>Dirk Zimmermann
> - * @version $Revision: 1.9 $
> + * @author mailto:[EMAIL PROTECTED]";>danch (Dan
Christopherson)
> + * @version $Revision: 1.10 $
> */
>public class JDBCLoadEntityCommand
> extends JDBCQueryCommand
> implements JPMLoadEntityCommand
>{
> + /**what is the position of each cmp field in the generated select
statement?
> +* this simply maps the position of the field in the CMP list to its
position
> +* in the generated select statement. This is neccessary because of
the variable
> +* number of key columns (which are skipped in a load) and because
there can
> +* be overlap between the two: pkfields and cmpfields are neither
disjoint sets
> +* nor is the cmpfields a subset of pkfields (not that that makes
sense to
> +* me right now, but I'll roll with it until I have more chance to
analyse - danch)
> +*/
> + int [] cmpFieldPositionInSelect = null;
> +
> + /** This const is used in places where I need to add an offset to a
count
> +* to account for the fact that JDBC counts from one whilst every
other
> +* damn thing in the languase starts at 0, the way God intended!
> +*/
> + private static final i
[JBoss-dev] Avoiding Locks for READ-ONLY Beans
Hello,
In order to avoid locking for TX or CTX in the
EntityInstanceInterceptor, I've basically added a flag to indicate whether the
bean can be optimized for read only operation. In the
EntityInstanceInterceptor, where the loop actually wait for the lock I've added
a condition
isReadOptimized = metadata.isReadOptimized();
if(!isReadOptimized)
{
...
...
go about as usual trying to aquire lock etc
}
mi.setEnterpriseContext(ctx);
return
getNext().invoke(mi);
and in the finally clause
if (ctx != null && (!isReadOptimized))
{
//business as usual code
}
What is good is that I no longer have my response times creeping up under
sustained loads.
Does
this look alright? Does anyone anticipate any other problems due to this. Would
really appreciate if folks who really have the 'bigger picture' can let me
know.
Thanks
Vinay
Re: [JBoss-dev] Verifier Issue - Shouldn't the RemoteInterface Class be checked as well?
Juha,
Have made the following changes:
1. AbstractVerifier
a) Added method
public boolean hasLegalRMIIIOPExceptionTypes(Method method) {
/*
* All checked exception classes used in method declarations
* (other than java.rmi.RemoteException) MUST be conforming
* RMI/IDL exception types.
*
* Spec 28.2.3 (4)
*/
Iterator it = Arrays.asList(method.getExceptionTypes()).iterator();
while (it.hasNext()) {
Class exception = (Class)it.next();
if (!isRMIIDLExceptionType(exception))
return false;
}
return true;
}
2. EJB11Verifier
a) Added check for exception types in the loop where you check for methods
as
if (!hasLegalRMIIIOPExceptionTypes(method)) {
fireSpecViolationEvent(entity, method, new
Section("9.2.7.h"));
status = false;
}
3. DefultMessages.properties
a) Added entry
9.2.7.h = The exception thrown by methods in the remote interface must be
valid types for RMI/IIOP
The output if I add an exception which is not a valid RMI/IIOP type looks
like
[Verifier]
Bean : ItemizedCallEntity
Method : public abstract ItemizedCall getItemizedCall() throws
RemoteException,
EJBException
Section: 9.2.7
Warning: The exception thrown by methods in the remote interface must be
valid types for RMI/IIOP
Am not sure where the sections are defined? Check the spec couldn't find
any specific location and hence just added it as section 9.2.7.h
Please let me know if this look alright.
Regards
Vinay
- Original Message -
From: "Juha Lindfors" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 05, 2001 9:06 PM
Subject: Re: [JBoss-dev] Verifier Issue - Shouldn't the RemoteInterface
Class be checked as well?
>
> Hi,
>
> At 14:47 4.6.2001 +0100, you wrote:
> >Well, that is well and fine. What is a bit
> >confusing is why the Verifier does not check if the RemoteInterface
itself
> >is a valid RMI type or not? Obviously, the verfyEntityRemote and
> >verifySessionRemote methods should check if the REMOTE class is a valid
> >RMI type so that it is specified explicitly an error by the Verifier!
>
> Ok, sure. That's a very good point. Do you have the time to fix that?
> Otherwise it'll have to wait.
>
> -- Juha
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Verifier Issue - Shouldn't the RemoteInterface Class be checked as well?
Will fix it. Cheers Vinay - Original Message - From: "Juha Lindfors" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 05, 2001 9:06 PM Subject: Re: [JBoss-dev] Verifier Issue - Shouldn't the RemoteInterface Class be checked as well? > > Hi, > > At 14:47 4.6.2001 +0100, you wrote: > >Well, that is well and fine. What is a bit > >confusing is why the Verifier does not check if the RemoteInterface itself > >is a valid RMI type or not? Obviously, the verfyEntityRemote and > >verifySessionRemote methods should check if the REMOTE class is a valid > >RMI type so that it is specified explicitly an error by the Verifier! > > Ok, sure. That's a very good point. Do you have the time to fix that? > Otherwise it'll have to wait. > > -- Juha > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Caching - Locking - Server Dies!
Ok, I know that reentrant beans can be quite a dangeroud beast at times. What if? 1. I create a bean and in the ejb-jar deploy it under 2 names - one reentrant and one not reentrant. 2. The re-entrant bean is used only for reads and the other one for writes. Does this sound complete rubbish? Jboss I believe creates only one bean even with commit option c. Why? Why can't we have multiple instances? Performance sucks with non-reentranet beans under high loads due to locking of the single instance. 3. Why can't we use the read-only flag to prevent locking? 4. Option D would do cache refreshes at fixed rates. But that sits after the EntityInstanceInterceptor and locking is done in the EntityInstanceInterceptor . Vinay - Original Message - From: "Dan OConnor" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 05, 2001 2:19 PM Subject: RE: [JBoss-dev] Caching - Locking - Server Dies! > Hi, > > A single component instance should only handle one request (i.e. > one thread) at a time, regardless of whether or not it is read only. > There is already an option to let the database handle > synchronization: commit option "C". (Obviously the component > must cooperate for read-write operations, either through optimistic > or pessimistic locking.) > > If the component uses commit option "C", it is allowable to have > multiple instances of a particular entity component associated with > the same primary key within a home. This is how to handle > concurrency of client requests for a single "glob of data"; not > through multiple threads in one component. > > Unfortunately, I think that JBoss still only allows one entity per key > within a home, even with commit option "C". If this is true, IMHO it > would be the best point of attack for this problem. > > Later, we can add a cache that might save on database hits for > read-only or read-mostly entity beans, duplicating some of the > speed advantages of commit option "A", without the scaling > disadvantages. Or for true read-only beans, we can allow commit > option "A" with multiple instances. Or in certain application > circumstances where perfect data consistency is not a design > goal, we can use commit option "D" with multiple read-write > instances, each with its own state cache maintained between > requests. > > -Dan O'Connor > > On 4 Jun 01, at 21:47, Bill Burke wrote: > > > Vinay, > > > > I'm pretty sure the EJB spec says that an instance of an EntityBean can only > > process one request at a time. I think this is what the Context lock is > > for. > > > > When you say that your bean is readonly, you mean that you defined it in > > JAWS as readonly? I'm pretty sure the code does NOT check to see if the > > EntityBean is JAWS and therefore doesn't check to see if it is readonly. > > > > IMHO, there should be an option to remove EntityBean locking and let the > > Database handle the synchronization either through the select-for-update > > option, or doing the locks in BMP. > > > > Bill > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of K.V. > > Vinay Menon > > Sent: Monday, June 04, 2001 6:17 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] Caching - Locking - Server Dies! > > > > > > Bill, > > I have tried both options. Started without a container transaction > > defined. In which case it kept throwing LOCKING-WAITING transactions [ from > > the EntityInstanceInterceptor] which says that JBoss is creating a > > transaction automatically. Next I changed the ejb-jar to specify the > > container transaction as REQUIRESNEW and as expected it did create a new > > transaction and hence showed the same messages. Finally, changed the > > container transaction to SUPPORTS when it stopped locking for the > > TRANSACTION and started locking waiting for the CTX [Context] in the else > > clause of the EntityInstanceInterceptor's invoke method. So there you go. > > Why is it locking for readonly bean? Why does it need to do it? The effects > > are only marginal and hardly detectable at low loads. It is more pronounced > > at higher loads and as the table size increase it goes into a real > > amplifying loop where the beans wait and take longer to return and that in > > turn cause the lock to be longer and so on. > > > > Strange that the method does not check for read-only attribute either? Why > > is that? > > > > Vinay > > - Original Message - > > Fro
Re: [JBoss-dev] Caching - Locking - Server Dies!
Thanks Gerog, Bill and Danch for your responses, It is all well and fine to say that sticking to the spec beans need to be single threaded and hence locking and the other stuff. What we must also appreciate is that for huge tables [for instance one of our tables has around 6 million records in there] performance suffers badly. The response time increases essentially exponentially. Since the JAWS xml does capture whether a bean is read-only or not why not use it for these kind of cases as well? And further I brought down my hit rate to about 10 clients at 1second. The response time initially was around 90ms and then grew to upto 4 mins. Trust me, it is diffcult to accept that kind of response times!! Regards, Vinay ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
