Balazs Borbely

Hi Arno, Is seams that you didn't run the question to see the result.
The result is S1 even the object what calls the method is an S2 instance.

Why is this way?

Because the the attributes are linked at compile time. -> not enabled for polymorphism.
For the methods instead, the decision (which method to call) is taken at run-time. -> polymorphism enabled

As it was said before, determine what part of the code is slow. You could use a profiler.

A few tips.
1. use batch for inserts
2. commit after each 1000 insert (the number can vary)
3. use threads, at least two,
- one thread reds the file, process the info and puts into a queue
- the second thread reads from the queue and executes the inserts into the db (the standard producer-consumer thread pattern)
4. use as few indexes as possible on that table, because at each insert the indexes are regenerated.
5. try to generate the XML using the db features for XML (I don't know about MSSQL but the Oracle has a reach XML feature set)

in the home interface you have to put the finder methods without 'ejb' prefix

in the home interface you will have
BMPRemote findByPrimaryKey(String str) throws FinderException ,RemoteException; Collection findAll(String str)throws FinderException ,RemoteException;

look into the driver jar file
in META-INF\MANIFEST.MF

Originally posted by Kris Reid:
Apparently the problem with Static variables is they are only available in a single JVM. Since I am running Sun App server on a single processor it will only have one JVM so no problem. Right??

You will have problems also if the JVM uses more than one class loader. If a class is loaded more than once in different class loaders than, each class loader will have his own static variables.
And the bad news is that, all J2EE app servers use different class loaders for different deployed applications.

I see 2 possible solutions.
1. Use a 'J2EE Singleton' a regular object and bound it in the JNDI tree.

2. Use some Caching strategy implemented trough AOP. (I am not sure if it is possible with ejbs)I implemented this kind of caching strategy for Spring.

A few possible solutions (I don't which would be applicable, depends on your business logic, and constraints)

-make those fields as number not text, since the area code is a 3 digit number and the phone number a 6 digits number.(number field + index=> good performance)
-if not you can use indexes on text fields as well

-use a professional database as Oracle (free for developers), or PostgreSQL (open source)

- use the same primary key for both tables , and that primary key should be a number, (the search on primary key is very fast)

You could try something like this:
--banned SELECT et.column1, et.column2, ... FROM excel_table et WHERE EXISTS (SELECT 1 FROM acces_table at WHERE et.phone_number = at.phone_number AND at.banned = true) --callable SELECT et.column1, et.column2, ... FROM excel_table et WHERE EXISTS (SELECT 1 FROM acces_table at WHERE et.phone_number = at.phone_number AND at.banned = false)

With the folowing preconditions.
- index on et.phone_number, at.phone_number, at.banned
- 'SELECT et.column1, et.column2, ... ' should have the minimum number of column required by application


PS. as a general rule EXISTS has a better performance than IN in most of the cases
[ March 03, 2006: Message edited by: Balazs Borbely ]

You can tag the version which is released to QA. If the QA founds bugs,
any time you can make a branch from that tag and fix it, and give it back to QA for retesting.

BUT those fixes should be added to the HEAD version as well.

assertEquals(Object obj1, Object obj2) uses the equalsmethod.

But new BigDecimal("2").equals(new BigDecimal("2.0") is false because the equals takes in consideration the scale as well.

Possible solutions:
1. use assertTrue(num1.compareTo(num2)==0);


2. set the same scale for both numbers

Go to the weblogic administration console and check if your bean is deployed and under what JNDI path.

The URL for the console should look like this.

http://hostname: port/console
[ January 29, 2006: Message edited by: Balazs Borbely ]

The container depending on his caching algorithm can call at any moment (except when the bean is in a transaction )the ejbPassivate.

After the lifetime of the EJB has expired (timeout) the ejbRemove will be called if the bean was in ready state; If it was already passivated than, is marked as deleted.

Give a look at 'tiles'.

UI design with Tiles and Struts
[ December 28, 2005: Message edited by: Balazs Borbely ]

Originally posted by Kudret Serin:
a || b
if a is true, b is not evaluated.
so is the same above.

Here is about a || b && c and && has a bigger precedence than || ... normally the b && c should be evaluated first.

Maybe the java implementation version is buggy.

A nice runtime exception: java.lang.ClassCastException

Since the Person class doesn't implement the Comparable interface.

The dynamic binding is applied [b]only[b] to methods.
So the attributes (class variables) are linked compile time.