Dain, please be patient with me, perhaps I simply don't know enough of what is possible with cmp2.
Is there a way to let a SLSB perform a statement directly on the jdbc datasource using _only_ eql? So do something like: "update SomeEntity set SomeField=5 where SomeOtherField=3" instead of: "update SomeTable set SomeColumn=5 where SomeOtherColumn=3" With "directly on the jdbc ds" I mean that the result should be the same as if I did invoke the equivalent sql through the jdbc driver. No bean cache affected, simply transform eql to sql and feed it into a jdbc statement. I am aware that "update" has no meaning for eql finders, but I hope you get the idea. Regards, Michael Dain Sundstrom wrote:
Now I am completely confused. What exactly do you want that you can't do today?
-dain
Michael Bartmann wrote:
Dain,
I'm a bit confused (especially by your phrase "in memory query") and I don't know if you
misunderstood me (or Pete's original post) or I misunderstand you.
I'll try to make clear what I meant:
1) we have a jboss with cmp2 container and deployed entities, so this container
knows how to handle eql, transform it into sql and send it to the jdbc layer.
2a) if you do mass queries or updates and you decide that you want to circumvent
the container/cache/interceptors for performance reasons you are normally bound
to "plain sql" queries to the jdbc layer. So you are forced to circumvent the
"tablename" -> "entityname" abstraction, the "columnname" -> "methodname"
abstraction and must handle db specific sql dialects.
2b) if we had means to let the container translate eql to sql because it knows the
relevant metadata, we could use it to feed it into jdbc, and only need to handle
the ResultSet iteration programmatically. There is no such thing as "in memor sql";
we would use the normal oracle/hypersonic whatsoever db the container uses for
is transactions.
You might argue that we should not need to use 2a or 2b anyway if make the container
really fast. And even readonly sql has to do transaction isolation right to not interfere
with the container and deadlock in the worst case.
But I must admit that we use "plain sql" in our application (which was developed under
jboss 2.4 first, which might count as an excuse). And loosing the eql abstraction is a
maintenance nightmare.
Just my 2cent,
Michael
Dain Sundstrom wrote:
Michael,
The idea for an in memory query engine is interesting, but this requires that all of you data to fit into memory and actually be in memory. If you want to write it, that would be cool, but I think there are way more important things to make CMP fast.
-dain
Michael Bartmann wrote:
Comments inline, Regards, Michael saroj kumar wrote:As I understand the main usecase: We _have_ entities (tereby xml) and containers, but haveRunning EJB-QL without Container/EB!!!! We need to consider few points. 1) If there is no container then how do we parse the XML?
a way to circumvent the container in case of queries, which would otherwise done
so in an inferiour fashion (pure sql).
2) If there are no Entity beans then how do you query?
We could have an mbean which has enough information from the container config
to convert eql to sql.
3) If Above points are sorted out then how do we achieve complex joins/unions?Good question; this is a shortcomming of eql (by design?).Again, we only consider a way to prevent a mixture of entities and plain sql in the
4) Moreover, In case of large projects, describing the schema in XML may
require some tools
Otherwise, the sheer sixe of DB will prevent users.
application, so thing can only get better.
This becomes crucial if the changes to DB are quite frequent.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:jboss-user-admin@;lists.sourceforge.net] On Behalf Of Michael
Bartmann
Sent: Wednesday, November 06, 2002 6:09 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help
Absolutely!
I don't have to add much to this, but I think that this request
(non-container ejb-ql) is so important (and a good "workaround",
too), that I simply couldn't resist to reply.
Anyway, would this be difficult to achieve?
Regards,
Michael Bartmann
Pete Beck wrote:
On Tue, 2002-10-29 at 17:28, Bill Burke wrote:myself
JBoss is being used in production everywhere. I've been at 6 sites
rightover the past year. IMHO and experience, entity beans are not the
By.choice if you're doing complex reporting. A handmade query cache with
direct JDBC will always be faster. Besides, EJB QL doesn't have Group
Regarding Bill's comment about reporting; this is *so* true. IMHO this
is one of the biggest problems that needs to be addressed in the EJB
spec.
However dropping to JDBC is not the answer either. Unfortunately,
there
is currently little choice.
What is needed is the ability to run queries directly in EJB-QL.
Having
to use JDBC means your application is dependent on the database domain.
In other words, the application designer has to know about the
implementation specifics of the persistence layer (database).
Being able to execute queries in EJB-QL would allow us to use bean
names
and property names.
-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
------------------------------------------------------------------------
**************************Disclaimer************************************************** Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited.
****************************************************************************************
-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
