Skip to Main Content

SQLcl

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

sqlcl 18.4 unsupported major.minor number 52.0

daniel_haukeJan 28 2019 — edited Aug 30 2019

Hi everybody,

i downloaded tht sqlcl version 18.4. When i try to start the sql command i get the following error:

Exception in thread "main" java.lang.UnsupportedClassVersionError: oracle/dbtools/raptor/scriptrunner/cmdline/SqlCli : Unsupported major.minor version 52.0

I know that this error is due to different version of java in our os and ORACLE_HOME. For some reason this version prefers the java from our ORACLE_HOME and not the java which is set in our PATH Variable.

Even if i set the $JAVA_HOME/bin at the beginning of our PATH the error occurs. I didn't get this error with the sqlcl 18.2.

The only way i found out is to unset our ORACLE_HOME. Then the  JAVA_HOME Variable is taken by the tool and i am able to start the sqlcl.

But unseting our ORACLE_HOME is not really an alternative for me.

So can anyone perhaps provide me a different workaround? Is it possible to tell sqlcl which java the tool should use to start?

Any tipp is appreciated!

Greetings Daniel

Comments

Alex Keh-Oracle
Asynchronous commands are not planned for the next ODP.NET release. I have not received too many requests for this feature, maybe since there are other ways to program asynchronously in .NET. If you have a business/technology case why you need use ODP.NET async commands (and why other asynch programming methods won't work well for you), send me an email


alex.keh (at) oracle.com

Alex Keh
ODP.NET Product Manager
Shrike
Alex,
I understand that you don't get many requests for this feature. Async programming is still pretty uncommon and complex. But there is some significant efforts from Microsoft to make it much easier. TPL (Task Parallel Library) is an example.

As for "other ways to program asynchronously in .NET" I have to say I completly disagree. RDBMS is resource manager and no one except itseft can do true asynchronous proccessing. Surely we can use ThreadPool for spliting execution logic onto 2 threads. It's asynchronous programming for sure, but it's not real asynchronous processing bacause we have the same threads count as in synch case (and even a bit more overheads). (out program logic can continue execution but these's a thread in threadpool waiting for DB's response and it's blocked)

Why do we need true async exucution in resource managers?
Image a server application. Let's it has a WCF-server MyService with a method GetData:
[ServiceContract]
public interface IMyService
{
[OperationContract]
public MyData GetData();
}
An implementation of this contract is creates OracleConenction, open it, create OracleCommand and executes it.
It's synchronous case.
Let out server app is under heavy load of concurrent users (300 for an example). And sql command which MyService is executing is pretty complex and takes OracleDB a couple of seconds to finish. What number of theads will out server app have? 300 at least. It's very very bad.
Yes, we can throttle requests into a queue, but then throughtput will be even less.

Now if we turn our WCF-service into asynchronous service with AsyncPatterns=true we'll get something like this:
[ServiceContract]
public interface IMyService
{
[OperationContract(AsyncPatterns=true)]
public IAsyncResult BeginGetData(AsyncCallback callback, Object state);
[OperationContract]
public MyData EndGetData(IAsyncResult ar);
}

WCF infrastructure would call out BeginGetData with its callback, our service implementation would call OracleCommand.BeginExecuteReader (if it exists) and a thread would return to threadpool. It wouldn't blocked waiting DB's response anymore. No threads would blocked!

With such scenario and using SQL Server (SqlClient supports APM) we saw a number of threads in server app in async case is 10 times less that sync case!
i.e. instead of 300 threads we got 30 threads!
It's impossible to achieve with OracleDB+odp+.net.
I can't say it's a blocking issue but I'm sure it's significant disadvantage.

p.s. True async processing is based on async device IO operations. So it probably has nothing to do wit ODP.NET itself but with unmanaged OracleClient.


Some resources:
- http://blogs.msdn.com/wenlong/archive/2009/02/09/scale-wcf-application-better-with-asynchronous-programming.aspx
- http://msdn.microsoft.com/en-us/magazine/cc163415.aspx
Alex Keh-Oracle
Shrike,
Thanks for your input. I'll discuss your business/technology case with my dev team and see if we can up the priority.
JD Donaldson
What was the result of this, if any? I need to exec sprocs asynch in ODP.net

-JD
JD Donaldson
https://apex.oracle.com/pls/apex/f?p=18357:46:8247669334277015::NO:::&success_msg=Action%20Processed.%2FA0D553125792CAB14742AD609D570327%2F
386312
Yes I too need async support and have decided to use SQL server instead.
944335
+1 I'd love to see that also. Async programming will shortly become common place with async/await native compiler support available for a while already. Support for true async I/O (when calling services/databases/...) will become mandatory in server solutions for scalability and efficiency reasons.

Yves
If this feature is important for you, please vote for it on our Feature Request Page:
http://apex.oracle.com/pls/apex/f?p=18357:46

Search for "ASYNCH". It currently has 13 votes.
1 - 8

Post Details

Added on Jan 28 2019
9 comments
3,457 views