This is nice and cool info from one of my colleagues. If you use Acrobat Reader 7.0, you can listen to the PDF. The following are the shortcuts:
ctrl + shift + b - To listen to the entire document
ctrl + shift + v - To listen to the current page
ctrl + shift + e - To Stop
ctrl + shift + c - To Resume
Very cool, isn't it. Try it out!!
Monday, June 26, 2006
Monday, June 19, 2006
Java Object to Oracle Object mapping
I had a requirement of passing large data to Oracle db and the various options I evaluated are:
1. Using PreparedStatements and batching the updates/inserts: Though this option seems apparent, I didn't consider it as a candidate for the reason that we need to use raw SQL statements and this violates our DB convention to use stored procs and functions. I'm not very sure if this would be fast either. So, dropped this option.
2. Using CLOBs: This would require a lot of change in the existing procs, so dropped it for the sake of reusing the existing procs. Someone, told me that CLOBs do not scale well.
3. Using Arrays: This is an elegant option. Most of the time, the data sent in bulk to DBs is primitive, ie, some numbers or strings or atmost encoded strings (NVARCHAR2). To evaluate sending info using array, I did the following:
a) created a table with just two columns first_name and last_name
b) created a oracle type to be a table of varchar2
create or replace type str_typ_t as table of varchar2(50);
c) created a stored proc to accept the string array as input and insert into the table.
d) The java class required some googling and experimentation, here is the code snippet:
ArrayDescriptor descriptor = ArrayDescriptor.createDescriptor("STR_TYP_T",conn);
ARRAY fnArray = new ARRAY(descriptor,conn,fnames);
That is all to be done. And I'm very happy to note the results. 300 inserts took just over a second!!!. This is Tres cool.
And if you would like to pass a java object to the stored proc and leave the mapping to the driver, the following lines would do the work:
StructDescriptor descriptor = StructDescriptor.createDescriptor("TEST_OBJ_T",conn);
Object[] attributes = {"ABCD","XYZ"};
STRUCT to = new STRUCT(descriptor,conn,attributes);
Some progress today. My PL/SQL skills have been really rusty, need more practice.
1. Using PreparedStatements and batching the updates/inserts: Though this option seems apparent, I didn't consider it as a candidate for the reason that we need to use raw SQL statements and this violates our DB convention to use stored procs and functions. I'm not very sure if this would be fast either. So, dropped this option.
2. Using CLOBs: This would require a lot of change in the existing procs, so dropped it for the sake of reusing the existing procs. Someone, told me that CLOBs do not scale well.
3. Using Arrays: This is an elegant option. Most of the time, the data sent in bulk to DBs is primitive, ie, some numbers or strings or atmost encoded strings (NVARCHAR2). To evaluate sending info using array, I did the following:
a) created a table with just two columns first_name and last_name
b) created a oracle type to be a table of varchar2
create or replace type str_typ_t as table of varchar2(50);
c) created a stored proc to accept the string array as input and insert into the table.
d) The java class required some googling and experimentation, here is the code snippet:
ArrayDescriptor descriptor = ArrayDescriptor.createDescriptor("STR_TYP_T",conn);
ARRAY fnArray = new ARRAY(descriptor,conn,fnames);
That is all to be done. And I'm very happy to note the results. 300 inserts took just over a second!!!. This is Tres cool.
And if you would like to pass a java object to the stored proc and leave the mapping to the driver, the following lines would do the work:
StructDescriptor descriptor = StructDescriptor.createDescriptor("TEST_OBJ_T",conn);
Object[] attributes = {"ABCD","XYZ"};
STRUCT to = new STRUCT(descriptor,conn,attributes);
Some progress today. My PL/SQL skills have been really rusty, need more practice.
Monday, June 05, 2006
Some useful hacks
Well.. it has been a while since I blogged. The primary reason being, I'm very busy with the work and trying to get adjusted to the new project env. The project uses lot of latest technologies, Oracle AQ/Streams, Web Services etc. Some useful hacks I have found last month -
Web Services - This is applicable only for the Axis platform. Axis persists the info of deployed web services to a file by name server-config.wsdd that is created under the WEB-INF. This file, incidentally, has a structure similar to that of the deploy.wsdd file. Instead of creating a deploy file and calling AdminClient from the command prompt, the same entries can be given in the server-config.wsdd and bouncing the server. When the server is started the web services get deployed. This is useful if the deployer of the project is not much aware of the Web services and their deployment processes.
*** Update ***
This is an info I often forget,well, in rush to publish the WS and consume it ;-). If proper description is not given about the methods exposed by the WS, the input arguments are exposed as in0, in1, in2, etc. A few additional lines in the WSDD expose the appropriate and intuitive info about the input parameters:
<operation name="theMethodName" qname="ns:qnameFortheMethod" returnQName="ns:theReturnTypeQNameofTheMethod" returnType="ns:theReturnType">
<parameter name="nameOfTheParameter" type="example-xsd:string"/>
</operation>
I had to recollect this when one of our testing team members said that the WSDL aren't descriptive about the input parameters.
NVarchar2 issue - I observed a strange "No more data to read from socket error" if the return type of the strings is NVarchar2. This was noticed with the Oracle 10g and the latest jdbc driver. Two hacks to overcome this are: a) Change the data type to Varchar2, if you have DB control b) add a java VM argument "-Doracle.jdbc.defaultNChar=true".
Other than work, there seems to be little time for life. Trying best to establish the work-life balance, ;-)
Web Services - This is applicable only for the Axis platform. Axis persists the info of deployed web services to a file by name server-config.wsdd that is created under the WEB-INF. This file, incidentally, has a structure similar to that of the deploy.wsdd file. Instead of creating a deploy file and calling AdminClient from the command prompt, the same entries can be given in the server-config.wsdd and bouncing the server. When the server is started the web services get deployed. This is useful if the deployer of the project is not much aware of the Web services and their deployment processes.
*** Update ***
This is an info I often forget,well, in rush to publish the WS and consume it ;-). If proper description is not given about the methods exposed by the WS, the input arguments are exposed as in0, in1, in2, etc. A few additional lines in the WSDD expose the appropriate and intuitive info about the input parameters:
<operation name="theMethodName" qname="ns:qnameFortheMethod" returnQName="ns:theReturnTypeQNameofTheMethod" returnType="ns:theReturnType">
<parameter name="nameOfTheParameter" type="example-xsd:string"/>
</operation>
I had to recollect this when one of our testing team members said that the WSDL aren't descriptive about the input parameters.
NVarchar2 issue - I observed a strange "No more data to read from socket error" if the return type of the strings is NVarchar2. This was noticed with the Oracle 10g and the latest jdbc driver. Two hacks to overcome this are: a) Change the data type to Varchar2, if you have DB control b) add a java VM argument "-Doracle.jdbc.defaultNChar=true".
Other than work, there seems to be little time for life. Trying best to establish the work-life balance, ;-)
Subscribe to:
Posts (Atom)