vishwas bansal

Greenhorn
+ Follow
since Dec 19, 2002
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
(keep public parts private until JForum day)
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt
Moderation Tools

Recent posts by vishwas bansal

set classpath=%classpath%;D:\oracle\ora81Serv\jdbc\lib\classes12.zip;
This how i hv set it..compare it with yours..it shud work.
its sum of input and output params.
You just cannot guarantee that Statement will always be recompiled.But you can be sure that pre-statement would not be recompiled.
Let's understand it taking an example...Hope im correct.
1)select * from emp (stmt)
2)select * from Emp (stmt)
3)select * from Emp (stmt)
oracle does a lexical comparison before actually looking for a pre-executed query in database..so query plan for 3 is found bcos it exactly matches with 2.So we cannot say that statement would always be compiled.
then comes the case of prepared statement.
it is useful when we are just querying for different values or inserting record.
we create prepared statement ... which actually places bind variables in place of values.
for ex:
1) select * from emp where ename = :a
:a=scott (setString method)
This willbe the query submitted to oracle.
2) select * from emp where ename = :a
:a=blake
This 2 queries are lexically same.So we can always guarantees that oracle will get the query plan after first execution.
hope things are clear..
according to my understanding ,
In EJB we have Ejbhome,EjbObject,EjbBean.We also have stubs and skeletons for EJBhome and EjbObject both lets traverse through Client code:
1) context.lookuphome()
This step will actually looks up for EJBHome and returns the caller EJBHome Stub.
Think of stubs as some network aware code which actually opening socket on Server where EJBHome SKeleton is listening for EJBHome Stub's request.
2) EJBHome.create()
This method is actually called on EJBHome STUB which we received after step 1.The call is send to EJBHomeSkeleton(more of RMI mechanism)
3) EJBObject <= after receiving it from step 2
The Call from EJBHome Skeleton is forwarded to already created EJBObject Skeleton which first instantiate the EJBBean ,keeps the reference in EJBObject skeleton and then EJBSkeleton returns the network aware EJBObject Stub.Which from
now onwards will be referred as our remote interface object in Client code.
4) So from now on whatever remote method we call on remote interface (EJBObject Stub received) will remotely Call those method on EJBObject skeleton, and in turn EJBObject skeleton will call our Bean's method.
Hope this would help..as I said according to my understanding.Though oreilley and Ed-roman would be better to refer.
you are very correct ,class.forname actually register and instantiate the driver class.you can have as much driver as you want.consider it to be a hashtable of drivers.when we give url it goes to check every driver class instance if it identifies the url and on success results the connection.
A default ResultSet object is not updatable .
following combinations for ResultSet Object's concurrency control are possible.
-----------------------------------
You can always chuckup Type-Forward_Only combinations those are pretty straight forward.

Type_Forward_Only/Concur_Read_Only
(pretty much static) retrieved and displayed with Navigation forward.
Type_Scroll_Insensitive/Concur_Read_Only
(pretty much static) retrieved and displayed with Navigation bothside.
Type_Scroll_Sensitive/Concur_Read_Only
(Changes reflected if SUB-SET is changed by Others,Navigation bothside.
-----------------------------------
Type_Forward_only/Concur_Updateable
Type_Scroll_Insensitive/Concur_Updateable
Type_Scroll_Sensitive/Concur_Updateable
All with Updateable attribute works in lock mode.But the result set may differ for databases.
For :Type_Scroll_Sensitive/Concur_Updateable

Oracle:The lock is obtained for the row we are updating,everybody else will see the snapshot of old row.As soon as commit takes place ,new Data will be reflected for users who are using sensitive attribute.
SQL:
A)All the users trying to get same result-set may get blocked.
B)If query ran using Select(NO-LOCK) then there is a threat of getting un-commited data from others users working in updatable mode.(assumed we are in sensitive mode.)
Hope this will help.