Re: [JBoss-dev] [ jboss-Bugs-420714 ] Call setRollbackOnly() in Enti
What is the transaction attribute? - Original Message - From:[EMAIL PROTECTED] Sent:Wednesday, May 02, 2001 2:57 PM To:[EMAIL PROTECTED] Subject:[JBoss-dev] [ jboss-Bugs-420714 ] Call setRollbackOnly() in Enti Bugs item #420714, was updated on 2001-05-02 06:38You can respond by visiting:http://sourceforge.net/tracker/?func=detailatid=376685aid=420714group_id=22866Category: JBossTXGroup: v2.2.1 (stable)Status: OpenResolution: NonePriority: 5Submitted By: Nobody/Anonymous (nobody)Assigned to: Nobody/Anonymous (nobody)Summary: Call setRollbackOnly() in Entity EJBInitial Comment:Hi,I made a little sample program, which uses a CMPEntity EJB. In one method of this bean I callsetRollbackOnly() in the EntityContext. All methodsof the bean have default transactional behaviour. Sowhen the method has finished, the transaction shouldroll back. When I call another method after that, theclient blocks. After a while (timeout) jBoss printserror messages saying, that the transaction marked forrollback still exist.If I throw the EJBException, then the transaction isrolled back, but the ejbStore() is called before that.This is behaviour wanted?Cheers,Dirk--You can respond by visiting:http://sourceforge.net/tracker/?func=detailatid=376685aid=420714group_id=22866___Jboss-development mailing list[EMAIL PROTECTED]http://lists.sourceforge.net/lists/listinfo/jboss-development Get your FREE download of MSN Explorer at http://explorer.msn.com
[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 related
* @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Joe Shevland/a
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
* @author a href=mailto:[EMAIL PROTECTED];Sebastien
Alborini/a
* @author a href=mailto:[EMAIL PROTECTED];Vinay Menon/a
* @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
*/
Object stableRowIdColumnValue=null;
int
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
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 modified_file [modified_file ...] 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! 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] 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 wayit 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 isit a joke ? any goodexample ofhow to run Tomcat with Jboss is welcomed. thanks
[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] 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] 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] 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] 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
jaws
datasourcejava:/PERSONAL/datasource
debugfalse/debug
type-mappingOracle8/type-mapping
enterprise-beans
entity
ejb-namePieParamEntity/ejb-name
datasourcejava:/BRILLOBER/datasource
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;
/**
* description
*
* @see related
* @author a href=[EMAIL PROTECTED]Sebastien Alborini/a
* @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
* @author a href=mailto:[EMAIL PROTECTED];Vinay Menon/a
* @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
[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
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
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 -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 28, 2001 9:53 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation also be sure to report right here is you touch any of the information in the ctx (using setters) marcf |-Original Message- |From:
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] 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] [ 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=detailatid=376685aid=438115group_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:
entity
ejb-nameEventDescription/ejb-name
finder
namefindByEventType/name
query, TypeDescriptionPair,
EventType WHERE EventType.description={0} AND
EventType.enumerationIndex=TypeDescriptionPair.eventTyp
eKey AND
TypeDescriptionPair.eventDescriptionKey=EventDescriptio
n.enumerationIndex/query
orderEventDescription.description/order
/finder
/entity
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
[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
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] Is the JBoss website down for maintenance?
___ 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
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
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 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
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.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] [ 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=detailatid=376685aid=439861group_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=detailatid=376685aid=439861group_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] 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] 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
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] [ 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=detailatid=376685aid=440167group_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=detailatid=376685aid=440167group_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] [ 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] 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 stable-rowid-columnrowid/stable-rowid-column 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
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:- !-- The datasource at bean level. If specified the bean will use this datasource instead of the global one. Else the global one is used -- !--ELEMENT datasource (#PCDATA)-- 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
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
[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-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 : 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 wait-option 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
[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
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 wait-option 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. type-mappings type-mapping-definition nameOracle8/name select-for-update-supportedtrue/select-for-update-supported select-for-update-format![CDATA[SELECT %i FROM %t WHERE %w FOR UPDATE]]/select-for-update-format select-for-update-no-wait-supportedtrue/select-for-update-supported select-for-update-no-wait-format![CDATA[SELECT %i FROM %t WHERE %w FOR UPDATE NOWAIT ]]/select-for-update-formatmapping java-typejava.lang.Boolean/java-type jdbc-typeBIT/jdbc-type sql-typeSMALLINT/sql-type /mapping 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 select-for-update wait=truetrue/select-for-update 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] 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 wait-option 2. Don't specify it if you don't need anything special. If you want a no wait option specify it as wait-optionNOWAITwait-option or any other option that is dbms specific 3. In the LoadEntityCommand append this text to the select for update sql if select-for-update has been specified to be true. Vinay ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[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
Re: [JBoss-dev] Enhydra vs. JBoss
And has dowe 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] 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] 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] 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
[JBoss-dev] Option D - Take Two!
and get that algo right and lightweight and we put it in.
regards
marc
PS: PLEASE READ THE CLASS EXCERCISE AND MY PREVIOUS MAIL :)
|
|Cheers,
|
|Vinay
|
|Just took a loo
|- Original Message -
|From: marc fleury [EMAIL PROTECTED]
|To: [EMAIL PROTECTED]
|Sent: Friday, May 11, 2001 7:12 PM
|Subject: RE: [JBoss-dev] RE: Option D - Take One !
|
|
| Vinay,
|
| // The valid variables, make it a hashset
| Map validContext;
|
| invoke(MI mi) {
|
| try {
| // Use the cache key, it is safe
| if (!validContext.contains(((EntityEnterpriseContext)
| mi.getEnterpriseContext()).key) {
|
| //The context is not in the map, it will be loaded in the next
|interceptor
| ctx.setValid(false);
|
| synchronized (validContext)
| // Add it to the map so that it is seen the next time
| validContext.add(... mi.getEnterpriseContext().key...);
| }
|
| invokeNext(mi);
|}
| finally {
|
| ctx.setValid(true);
| }
|
| // The thread that does the work should only do the following
| synchronized (validContext)
| validContext.clear();
|
| The way this work is that when the thread wakes up it removes
|all the keys
| from the valid instances.
|
| You start there is no one in the valid stuff, if a call comes it gets a
|map
| miss and asks for the instance to be reloaded. The next time a
|call comes
| the instance is in the map the ctx is still at valid and the next
| interceptor won't load the instance.
| When the thread wakes up it empties the map so that the threads coming
in
| through invoke see that the instance isn't in the validContexts and
asks
|for
| a reload of it.
|
| I don't believe that the synchronization of the map is really necessary
|(at
| all) and if it is I don't see it as needed other than the place where
|there
| is structural changes. A miss will mean a reload so that treats the
|state
| in a safe way.
|
| regards
|
| marc
|
|
| |-Original Message-
| |From: [EMAIL PROTECTED]
| |[mailto:[EMAIL PROTECTED]]On Behalf Of
K.V.
| |Vinay Menon
| |Sent: Friday, May 11, 2001 11:29 AM
| |To: [EMAIL PROTECTED]
| |Subject: Re: [JBoss-dev] RE: Option D - Take One !
| |
| |
| |Hi Simon.
| |Thanks for the response. I must admit that I have really
|not dug deep
| |into the guts of quite a few classes in JBoss. Why I put it in
|a separate
| |Interceptor is
| |
| |1. Does not become part of standard jboss release if we go for spec
| |compliance and stuff!
| |2. Users can add and remove it as required from the jboss.xml so that
|they
| |have more control over it.
| |3. Code does not really touch any other code classes [except for the
| |metadata bit]
| |
| |
| |Vinay
| |- Original Message -
| |From: Bordet, Simone [EMAIL PROTECTED]
| |To: JBoss Development Mailing List (E-mail)
| |[EMAIL PROTECTED]
| |Sent: Friday, May 11, 2001 4:18 PM
| |Subject: [JBoss-dev] RE: Option D - Take One !
| |
| |
| | Hey Vinay,
| |
| | [please plain text email]
| |
| | Hello Folks,
| | Took a wild shot at the Option D, timed cache invalidation.
| | Have put it in a separate interceptor that sits before the
| | EntitySynchronizationInterceptor and invalidates the
| | EntityEnterpriseContext at regular preset intervals.
| |
| | I would have written a simple TimerTask in a LRU cache policy, as
I've
| |done
| | for the stateful bean removal.
| | The issues (entity beans invalidation and stateful beans
| |removal) are very
| | similar, aren't they ?
| |
| | 1. There is an invalidation timer task per entity bean [I
| | persum per-EntityEnterpriseContext maps to per bean and not
| | per bean instance]
| |
| | I saw you use java.util.TimerTask.
| | I reimplemented them because in the early days we wanted to be
|compatible
| | with jdk1.2.2, and these classes were added only in JDK 1.3. I don't
|know
| |if
| | this constraint is still there (running the server in a 1.2.2 JVM)
|but...
| |
| | 2. The refersh rate is currently set at 60secs but could be
| | moved elsewhere to the jboss config xml
| |
| | OK
| |
| | 3. The Configuration Metadat now has an entry for option D.
| |
| | OK
| |
| | 4. The interceptor does NOT reload the entity. It just
| | invalidates the cache. The entity reload is managed by the
| | EntitySynchronizationInterceptor.
| |
| | YES
| |
| | Does anyone want to go thru this and get back to me?
| |
| | As I've pointed out I would have written it with a
| |org.jboss.util.TimerTask
| | in a LRUEntityContextCachePolicy subclass.
| | In there I would have locked the cache, walked all the cached
context
|and
| | call setValid(false) on them, more or less like in the
| | LRUStatefulContextCachePolicy.
| | What do you think ?
| |
| | Cheers,
| |
| | Simon
| |
| | ___
| | Jboss-development mailing list
| | [EMAIL PROTECTED]
| | http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Option D- Take 2.1 - With Simone's TimerQueue and TimerTask
Here is the same code but with the TimerQueue and
TimerTask from Simone.
Vinay
/** JBoss, the OpenSource EJB server**
Distributable under LGPL license.* See terms of license at
gnu.org.*/package org.jboss.ejb.plugins;
import java.lang.reflect.Method;import
java.rmi.RemoteException;import java.rmi.ServerException;import
java.util.HashSet;import javax.ejb.EJBObject;import
javax.ejb.CreateException;import javax.ejb.EJBException;import
javax.ejb.NoSuchEntityException;import javax.ejb.RemoveException;import
javax.ejb.EntityBean;import javax.transaction.Status;import
javax.transaction.Synchronization;import
javax.transaction.Transaction;import
javax.transaction.TransactionManager;import
javax.transaction.RollbackException;import
javax.transaction.SystemException;
import org.jboss.ejb.Container;import
org.jboss.ejb.EntityContainer;import
org.jboss.ejb.EntityPersistenceManager;import
org.jboss.ejb.EntityEnterpriseContext;import
org.jboss.ejb.EnterpriseContext;import
org.jboss.ejb.InstanceCache;import org.jboss.ejb.InstancePool;import
org.jboss.ejb.MethodInvocation;import
org.jboss.metadata.ConfigurationMetaData;import
org.jboss.logging.Logger;import org.jboss.util.TimerQueue;import
org.jboss.util.TimerTask;
public class SoftBallInterceptorextends
AbstractInterceptor{ /** *
Commit Option from standardjboss.xml or jboss.xml
*/ protected int commitOption;
/** * The container of this
interceptor. */ protected
EntityContainer container;
/** * Collection of context
cache keys */ protected
HashSet ctxToInvalidate = new HashSet();
/** * The cache
refresh rate */ private static
int REFRESH_RATE = 3;
public void setContainer(Container
container) {
this.container = (EntityContainer)container; }
public void init() throws
Exception {
commitOption =
container.getBeanMetaData().getContainerConfiguration().getCommitOption();
if(commitOption ==
ConfigurationMetaData.D_COMMIT_OPTION)
{ //Start Timer
Task Now! new
SoftBallScheduler().schedule(new
SoftBallSynchronizer(REFRESH_RATE));
} }
public Container getContainer()
{ return
container; }
private void register(EntityEnterpriseContext ctx,
Transaction tx) { }
private void deregister(EntityEnterpriseContext
ctx) { }
// Interceptor implementation
--
public Object invokeHome(MethodInvocation
mi) throws Exception
{ return
getNext().invokeHome(mi);
}
public Object invoke(MethodInvocation
mi) throws Exception
{ if(commitOption ==
ConfigurationMetaData.D_COMMIT_OPTION)
{
EntityEnterpriseContext ctx =
(EntityEnterpriseContext)mi.getEnterpriseContext();
//In case the
invalidator thread wakes
up!
synchronized(ctxToInvalidate)
{
//Check if already
present?
if(!this.ctxToInvalidate.contains(ctx.getCacheKey()))
{
//If not invalidate
cache
ctx.setValid(false);
//and add to the set to make sure it is skipped next
time
this.ctxToInvalidate.add(ctx.getCacheKey());
}
} }
return
getNext().invoke(mi); }
/** * The implementation for
the TimerQueue that will actually run the * timed
task for us. */private static final class
SoftBallScheduler{private static final TimerQueue
m_SoftBallScheduler = new
TimerQueue();static{m_SoftBallScheduler.start();}public
final void schedule(TimerTask
t){schedule(t,
0);}public final void schedule(TimerTask t, long
delay){m_SoftBallScheduler.schedule(t,
delay);}}
/**
* */ private class
SoftBallSynchronizer extends
TimerTask {
SoftBallSynchronizer(long refreshRate)
{
super(refreshRate); }
public void
execute()
{
synchronized(ctxToInvalidate)
{
//Clear the set. Will force invalidation next time
on.
ctxToInvalidate.clear();
} }
}}
Vinay Menon
ISe-net SolutionsCarphone Warehouse plcwww.carphonewarehouse.com
+44-2088968038 (W)+44-7801054259
(M)+44-7808470016 (F)[EMAIL PROTECTED]
Re: [JBoss-dev] Option D - Take Two!
: Friday, May 11, 2001 7:12 PM
| |Subject: RE: [JBoss-dev] RE: Option D - Take One !
| |
| |
| | Vinay,
| |
| | // The valid variables, make it a hashset
| | Map validContext;
| |
| | invoke(MI mi) {
| |
| | try {
| | // Use the cache key, it is safe
| | if (!validContext.contains(((EntityEnterpriseContext)
| | mi.getEnterpriseContext()).key) {
| |
| | //The context is not in the map, it will be loaded in the next
| |interceptor
| | ctx.setValid(false);
| |
| | synchronized (validContext)
| | // Add it to the map so that it is seen the next time
| | validContext.add(... mi.getEnterpriseContext().key...);
| | }
| |
| | invokeNext(mi);
| |}
| | finally {
| |
| | ctx.setValid(true);
| | }
| |
| | // The thread that does the work should only do the following
| | synchronized (validContext)
| | validContext.clear();
| |
| | The way this work is that when the thread wakes up it removes
| |all the keys
| | from the valid instances.
| |
| | You start there is no one in the valid stuff, if a call comes
|it gets a
| |map
| | miss and asks for the instance to be reloaded. The next time a
| |call comes
| | the instance is in the map the ctx is still at valid and the next
| | interceptor won't load the instance.
| | When the thread wakes up it empties the map so that the threads
coming
|in
| | through invoke see that the instance isn't in the validContexts and
|asks
| |for
| | a reload of it.
| |
| | I don't believe that the synchronization of the map is really
|necessary
| |(at
| | all) and if it is I don't see it as needed other than the place
where
| |there
| | is structural changes. A miss will mean a reload so that treats
the
| |state
| | in a safe way.
| |
| | regards
| |
| | marc
| |
| |
| | |-Original Message-
| | |From: [EMAIL PROTECTED]
| | |[mailto:[EMAIL PROTECTED]]On Behalf Of
|K.V.
| | |Vinay Menon
| | |Sent: Friday, May 11, 2001 11:29 AM
| | |To: [EMAIL PROTECTED]
| | |Subject: Re: [JBoss-dev] RE: Option D - Take One !
| | |
| | |
| | |Hi Simon.
| | |Thanks for the response. I must admit that I have really
| |not dug deep
| | |into the guts of quite a few classes in JBoss. Why I put it in
| |a separate
| | |Interceptor is
| | |
| | |1. Does not become part of standard jboss release if we go for spec
| | |compliance and stuff!
| | |2. Users can add and remove it as required from the jboss.xml so
that
| |they
| | |have more control over it.
| | |3. Code does not really touch any other code classes [except for
the
| | |metadata bit]
| | |
| | |
| | |Vinay
| | |- Original Message -
| | |From: Bordet, Simone [EMAIL PROTECTED]
| | |To: JBoss Development Mailing List (E-mail)
| | |[EMAIL PROTECTED]
| | |Sent: Friday, May 11, 2001 4:18 PM
| | |Subject: [JBoss-dev] RE: Option D - Take One !
| | |
| | |
| | | Hey Vinay,
| | |
| | | [please plain text email]
| | |
| | | Hello Folks,
| | | Took a wild shot at the Option D, timed cache invalidation.
| | | Have put it in a separate interceptor that sits before the
| | | EntitySynchronizationInterceptor and invalidates the
| | | EntityEnterpriseContext at regular preset intervals.
| | |
| | | I would have written a simple TimerTask in a LRU cache policy, as
|I've
| | |done
| | | for the stateful bean removal.
| | | The issues (entity beans invalidation and stateful beans
| | |removal) are very
| | | similar, aren't they ?
| | |
| | | 1. There is an invalidation timer task per entity bean [I
| | | persum per-EntityEnterpriseContext maps to per bean and not
| | | per bean instance]
| | |
| | | I saw you use java.util.TimerTask.
| | | I reimplemented them because in the early days we wanted to be
| |compatible
| | | with jdk1.2.2, and these classes were added only in JDK
|1.3. I don't
| |know
| | |if
| | | this constraint is still there (running the server in a 1.2.2
JVM)
| |but...
| | |
| | | 2. The refersh rate is currently set at 60secs but could be
| | | moved elsewhere to the jboss config xml
| | |
| | | OK
| | |
| | | 3. The Configuration Metadat now has an entry for option D.
| | |
| | | OK
| | |
| | | 4. The interceptor does NOT reload the entity. It just
| | | invalidates the cache. The entity reload is managed by the
| | | EntitySynchronizationInterceptor.
| | |
| | | YES
| | |
| | | Does anyone want to go thru this and get back to me?
| | |
| | | As I've pointed out I would have written it with a
| | |org.jboss.util.TimerTask
| | | in a LRUEntityContextCachePolicy subclass.
| | | In there I would have locked the cache, walked all the cached
|context
| |and
| | | call setValid(false) on them, more or less like in the
| | | LRUStatefulContextCachePolicy.
| | | What do you think ?
| | |
| | | Cheers,
| | |
| | | Simon
| | |
| | | ___
| | | Jboss-development mailing list
| | | [EMAIL PROTECTED]
| | | http
[JBoss-dev] Option D - 3
Marc,
Have changed the name of the
map!
Also,
standardjboss.xml has a node
optiond-refresh-rate30/optiond-refresh-rate
that is along side the commit-option
node.
that specifies the refresh rate in seconds.
Ifoption d is specified then this value is read to set the refresh rate.
If the user forgets to specify this then the minimum for this [i.e. the max
refresh rate] is defaulted to 5 seconds [Do we want to make this higher i.e. 20
seconds or something?]
ConfigurationMetaData has been modified to handle
the new option as under
public static final byte D_COMMIT_OPTION =
3;public static final String[] commitOptionStrings = { "A", "B",
"C","D" };
Also it has a new method to return the refresh
rate read from the xml as
//Option D Refresh Rate
optiondrefreshrate = getElementContent(getOptionalChild(element,
"optiond-refresh-rate"),optiondrefreshrate);
public long
getOptionDRefreshRate() { return
Long.parseLong((optiondrefreshrate!=null)?optiondrefreshrate:"0")*1000;
}
And finally the modified class is as follows. Am
not sure whether it should still be called SoftBallInterceptor though! Also, if
'optiond-refresh-rate' sounds odd we might want to change that!
And yes, I am looking forward to getting the
t-shirt in 2 weeks time when you come down to CPW!
Regards
Vinay
/** JBoss, the OpenSource EJB server**
Distributable under LGPL license.* See terms of license at
gnu.org.*/package org.jboss.ejb.plugins;
import java.lang.reflect.Method;import
java.rmi.RemoteException;import java.rmi.ServerException;import
java.util.HashSet;import javax.ejb.EJBObject;import
javax.ejb.CreateException;import javax.ejb.EJBException;import
javax.ejb.NoSuchEntityException;import javax.ejb.RemoveException;import
javax.ejb.EntityBean;import javax.transaction.Status;import
javax.transaction.Synchronization;import
javax.transaction.Transaction;import
javax.transaction.TransactionManager;import
javax.transaction.RollbackException;import
javax.transaction.SystemException;
import org.jboss.ejb.Container;import
org.jboss.ejb.EntityContainer;import
org.jboss.ejb.EntityPersistenceManager;import
org.jboss.ejb.EntityEnterpriseContext;import
org.jboss.ejb.EnterpriseContext;import
org.jboss.ejb.InstanceCache;import org.jboss.ejb.InstancePool;import
org.jboss.ejb.MethodInvocation;import
org.jboss.metadata.ConfigurationMetaData;import
org.jboss.logging.Logger;import org.jboss.util.TimerQueue;import
org.jboss.util.TimerTask;
public class SoftBallInterceptorextends
AbstractInterceptor{ /** *
Commit Option from standardjboss.xml or jboss.xml
*/ protected int commitOption;
/** * The container of this
interceptor. */ protected
EntityContainer container;
/** * Collection of context
cache keys */ protected
HashSet validContexts = new HashSet();
/** * The minimum
cache refresh rate. If its anything below 5 seconds default
to * minimum
*/ private static long MINIMUM_REFRESH_RATE = 5000;
/** * Standard method
implementation */ public void
setContainer(Container container)
{ this.container =
(EntityContainer)container; }
/** * Standard method
implementation */ public
Container getContainer()
{ return
container; }
/** *
Initializer */ public void
init() throws Exception
{ //Get Commit option from the
jboss/standardjboss xml config
file commitOption =
container.getBeanMetaData().getContainerConfiguration().getCommitOption();
if(commitOption ==
ConfigurationMetaData.D_COMMIT_OPTION)
{ long
refreshRate =
container.getBeanMetaData().getContainerConfiguration().getOptionDRefreshRate();
//Sanity Check
refreshRate =
(refreshRateMINIMUM_REFRESH_RATE)?MINIMUM_REFRESH_RATE:refreshRate;
//Start Timer
Task Now! new
SoftBallScheduler().schedule(new
SoftBallSynchronizer(refreshRate));
} }
// Interceptor implementation
--
public Object invokeHome(MethodInvocation
mi) throws Exception
{ //Simply pass on to the
next interceptor return
getNext().invokeHome(mi); }
public Object invoke(MethodInvocation
mi) throws Exception
{ if(commitOption ==
ConfigurationMetaData.D_COMMIT_OPTION)
{
EntityEnterpriseContext ctx =
(EntityEnterpriseContext)mi.getEnterpriseContext();
//In case the
invalidator thread wakes
up!
synchronized(validContexts)
{
//Check if already
present?
if(!this.validContexts.contains(ctx.getCacheKey()))
{
//If not invalidate
cache
ctx.setValid(false);
//and add to the set to make sure it is skipped next
time
this.validContexts.add(ctx.getCacheKey());
}
} }
//Pass on to the next
interceptor return
getNext().invoke(mi); }
/** * The implementation for
the TimerQueue that will actually run the * timed
task for us. */private static final class
SoftBallScheduler{private static final TimerQueue
m_SoftBallScheduler = new
TimerQueue();static{m_SoftBallScheduler.start();}public
final void schedule(TimerTask
t){schedule(t,
0);}public final void schedule(TimerTask t, long
Re: [JBoss-dev] add-on for JBOSS
If there is good integration betwee NetBeans and JBoss will that be passed on to say something like Forte for Java Community edition? Vinay - Original Message - From: aswath satrasala [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, May 12, 2001 2:42 PM Subject: RE: [JBoss-dev] add-on for JBOSS Thanks for sharing the thought. I am working on netbeans open source a little bit.(It is a Java development IDE) I am user of jboss a little bit for learning EJB I think there is a good business opportunity on integrating these two great products. Are there any commercial or open source products based on the tight integration between netbeans and jboss? Are anyone interested in this kind of effort, and work on adding value/infrastructure for both netbeans and jboss. From message archives, I see a lot of companies using JBOSS for almost commercial purposes. Can users of the those companies give an input on this. -Aswath From: marc fleury [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] add-on for JBOSS Date: Fri, 11 May 2001 23:19:04 -0400 Hello, yes it is legal to develop commercial add-ons to JBoss. In fact if you wanted to sell it through JBoss.org we would put it on our download page and charge for every sale. We are a distribution channel and your sales help pay for the development of the core. marc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |aswath satrasala |Sent: Friday, May 11, 2001 7:43 PM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] add-on for JBOSS | | |Hello All, |Are there any commercial vendors developing |modules or add-ons connected with JBOSS | |Is it legal to develop/package commercial |products based on JBOSS? |If there were already discussions on this subject, |point me to those emails or archives. | |Thanks |-Aswath | | | |_ |Get your FREE download of MSN Explorer at http://explorer.msn.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 _ Get your FREE download of MSN Explorer at http://explorer.msn.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] Verifier Issue - Shouldn't the RemoteInterface Class be checked as well?
Juha, When Verifying EJBs deployed the Verifier checks for RMI types in the return values and in the arguments and ensures that an RMIException is thrown by the method itself. Do we also want to add a clause to check if the class itself [only for the Remote Interface class] is a valid RMI type? For instance if I accidentally specified that a method in my 'REMOTE' interface throws EJBException, the Verfier comes up with an excpetion [Verifier]Bean : ItemizedCallEntityMethod : public abstract ItemizedCallEntityRemote findByPrimaryKey(ItemizedCallEntityPK) throws RemoteException, FinderExceptionSection: 9.2.8Warning: The method return values in the home interface must be of valid types for RMI/IIOP. The reason being that EJBException is not a valid RMI Exception type [??]. 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! Cheers, Vinay
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
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 - From: Bill Burke To: [EMAIL PROTECTED] Sent: Monday, June 04, 2001 9:10 PM Subject: RE: [JBoss-dev] Caching - Locking - Server Dies! If an Entity is loaded within a transaction it is locked until the transaction completes. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of K.V. Vinay Menon Sent: Monday, June 04, 2001 12:59 PM To: User @ JBoss; Dev @ JBoss Subject: [JBoss-dev] Caching - Locking - Server Dies! Hello Folks, Continuing with my load test I find something strange. I have a test harness
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] 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
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 a href=mailto:[EMAIL PROTECTED];Justin Forder/a
* @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
- * @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 a href=mailto:[EMAIL PROTECTED];Joe Shevland/a
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
* @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
- * @version $Revision: 1.9 $
+ * @author a href=mailto:[EMAIL PROTECTED];danch (Dan
Christopherson)/a
+ * @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 int JDBC_WART_OFFSET = 1;
// Constructors
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
[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; }
//Added
by Vinay Menon - Start //If
a rowid [as in Oracle is present use it to optimize updates and
deleted rowIDColumnName =
getElementContent(getOptionalChild(element,
"rowid-column")); //Added by Vinay
Menon - End
This way all you need in your ejb is a cmp field
with the corresponding name [or mapped to the corresponding column in jaws.xml].
Updates and Deletes will use this column for all their sqls. Note that updates
will NOT update the rowid-column column. If nothing is specified in jaws.xml
defaults are used.
Sample SQLs generated would look like
DELETE FROM itemizedcall WHERE
ROWID=?
or
DELETE FROM itemizedcall WHERE accountnumber=? AND
mobilenumber=? AND invoicenumber=? AND itemizedcallnumber=?
and
UPDATE itemizedcall SET
itemizedcallnumber=?,callcost=?,callduration=?,mobilenumber=?,accountnumber=?,invoicenumber=?,calltype=?
WHERE ROWID =?
or
UPDATE it
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 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
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
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 select-for-update 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] 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, that wait on the same
instance should wake up. Please remember, I'm unexperienced with
multithreding and JBoss, just lost on this.
___ ___
| + |
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 column 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 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. snip ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net
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
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 column 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
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
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: [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! snip/ ___ 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] 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
[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
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
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
[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
String
stableRowIdColumn = jawsEntity.getStableRowIdColumn();
String
sql;
/** * If the stable rowid column was
specified in the jaws.xml then use it *
for delete operations. Else use the standard PK based
delete.
*/
if(stableRowIdColumn!=null)
{ // Remove
SQL sql = "DELETE FROM
" + jawsEntity.getTableName() +" WHERE
"+stableRowIdColumn+"=?";
} else
{ // Remove
SQL sql = "DELETE FROM
" + jawsEntity.getTableName()
+
" WHERE "+getPkColumnWhereList(); }b)
setParameters
String
stableRowIdColumn = jawsEntity.getStableRowIdColumn();
int
i=0;
//If the stable
rowid coulumn was specified get its value and set
param if(stableRowIdColumn!=null
)
{ Iterator iter =
jawsEntity.getCMPFields();
while (iter.hasNext())
{
CMPFieldMetaData cmpField = (CMPFieldMetaData)iter.next();
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
Re: [JBoss-dev] ROWID Based Update: Load Entity Before Store Entity
Hello Georg, Nope! That is whatI 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] 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] 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
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.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 ___ 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] 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
| - getter method
| - setter method
| - 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
[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-dev] Logging Cache Hits
Hi, Does anyone know how to turn on cache hit tracking in JBoss without recompiling the code!? Is this possible? I am trying to stress JBoss to about as far as it can get [it has not yet fallen over!!! ] but the time for queries seem a bit odd. I have large intial retrieval times and then they fall off [as expected I guess dues to cache hits - want to confirm this though]. But I do get spikes in the middle [probably because the number of beans has reached a stage where passivation kicks in]. What I'd like to know is whether successive queries actually hit the database or work [as promised] by hitting the cache even under very high loads. I am testing with about 1 client threads hitting the application server any where between 10milliseconds to about 1000 milliseconds on a huge Tru64 box. The queries could return 1,15,150,1250 records depending on the type of client. The underlying table has about half a million records and is an Oracle 8i database. Regards, Vinay
[JBoss-dev] Fw: Caching - Locking - Server Dies!
Hi,
The following seems to be the code,
// Get
context
ctx = cache.get(key);
// Do we have a running transaction with the
context
Transaction tx =
ctx.getTransaction();
if (tx != null
// And are we trying to enter with another
transaction
!tx.equals(mi.getTransaction()))
{
// Let's put the thread to sleep a lock release will wake the
thread
// Possible
deadlock
Logger.debug("LOCKING-WAITING (TRANSACTION) for id "+ctx.getId()+" ctx.hash
"+ctx.hashCode()+" tx:"+((tx == null) ? "null" : tx.toString()));
// Try your luck
again
ctx =
null;
continue;
for the EntityInstanceInterceptor that actually causes this condition. I
have NOT specified any assembly descriptors in my ejb-jar.xml. What transaction
mode does JBoss then default to?
Vinay
- Original Message -
From: K.V. Vinay Menon
To: User @ JBoss ; Dev @ JBoss
Sent: Monday, June 04, 2001 5:58 PM
Subject: Caching - Locking - Server Dies!
Hello Folks,
Continuing with my load test I
find something strange. I have a test harness that simulates 100 clients hitting
the server at 100ms. They all retrieve the same data - 150 odd
records - from the database. The cache size has been set to 10. Commit
option is A. Am not doing any write operations.
1. The retrieve for the first client is high as
expected.
2. This then falls rapidly to about 90ms.
3. However the response time then rises to aout 20
seconds.
On checking the server log, I am getting loads of
'LOCKING-WAITING (TRANSACTION)' messages. And its due to this locking I
presume that the response time takes a beating.
a) Why is it not just reading data from
cache?
b) Why is it locking for read only
opertions?
Why is this so? All this seems very strange.
Either I am missing something or the caching is not working for high loads.
Regards,
Vinay
[JBoss-dev] Caching - Locking - Server Dies!
Hello Folks, Continuing with my load test I find something strange. I have a test harness that simulates 100 clients hitting the server at 100ms. They all retrieve the same data - 150 odd records - from the database. The cache size has been set to 10. Commit option is A. Am not doing any write operations. 1. The retrieve for the first client is high as expected. 2. This then falls rapidly to about 90ms. 3. However the response time then rises to aout 20 seconds. On checking the server log, I am getting loads of 'LOCKING-WAITING (TRANSACTION)' messages. And its due to this locking I presume that the response time takes a beating. a) Why is it not just reading data from cache? b) Why is it locking for read only opertions? Why is this so? All this seems very strange. Either I am missing something or the caching is not working for high loads. Regards, Vinay
[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 a href=mailto:[EMAIL PROTECTED];Vinay Menon/a
* @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson)/a
* @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a
- * @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
[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 a href=mailto:[EMAIL PROTECTED];Michel de Groot/a
* @author a href=mailto:[EMAIL PROTECTED];Vinay Menon/a
* @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
- * @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/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 stable-rowid-column 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 a href=[EMAIL PROTECTED]Sebastien Alborini/a
* @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
* @author a href=mailto:[EMAIL PROTECTED];Vinay Menon/a
- * @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
[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 @@ !ELEMENT debug (#PCDATA) -!ELEMENT default-entity (create-table, remove-table, tuned-updates, read-only, pk-constraint?, select-for-update?, time-out) +!ELEMENT default-entity (create-table, remove-table, tuned-updates,stable-rowid-column?, read-only, pk-constraint?, select-for-update?, time-out) !ELEMENT create-table (#PCDATA) !ELEMENT remove-table (#PCDATA) !ELEMENT tuned-updates (#PCDATA) @@ -59,7 +59,7 @@ time-out: For read-only only, re-load entity after time-out -- !ELEMENT entity (ejb-name,datasource?,cmp-field*,finder*,read-ahead?,read-only?, - table-name?,tuned-updates?,create-table?,remove-table?,select-for-update?,time-out?,pk-constraint?) + table-name?,tuned-updates?,stable-rowid-column?,create-table?,remove-table?,select-for-update?,time-out?,pk-constraint?) !-- ejb-name within an entity element must contain the ejb-name as specified in ejb-jar.xml. -- @@ -67,6 +67,18 @@ !-- The datasource at bean level. If specified the bean will use this datasource instead of the global one. Else the global one is used -- !ELEMENT datasource (#PCDATA) + +!-- +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 stable-rowid-column with value = rowid + +It should default to the primary key in case the row id is null - insert-update or insert-delete or combinations +-- + +!ELEMENT stable-rowid-column (#PCDATA) !ELEMENT cmp-field (field-name, column-name) !ELEMENT field-name (#PCDATA) !ELEMENT column-name (#PCDATA) ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
