| |
| |
| |
|
Page: 1 2 3 4 5
Comments:
<0> heh no kiddin
<1> well, dog round, see you later. :)
<0> hasta
<0> ugh we have been *ordered* to do regression testing for the intenet bleh
<0> long live intrAnet!
<2> Hi all
<3> whodis : i think the secret is to learn in advance with minimal effort
<3> whodis : and if by any means possible on company time
<4> *^*&^^ jdbc objects and needs for explicit clears....
<5> kmh : i hear ya man. that's what i'm doing right this moment as a matter of fact
<5> kmh : most of the pittsburgh market is for j2ee positions, and i am a 3 year java veteran so its mostly a natural progression. also: i've convinced my current boss that ejb's were worth "looking into" ;-)
<3> whodis : smart choice :)
<5> should there be a reason that i can't access a local bean from a remote bean in ejb2.0
<6> whodis: local where?
<5> i have a servlet running on sun appserver 8.2. it accesses a "remote" session bean. i want the session bean to access an entity bean in a LOCAL fashion. all 3 components are on the same physical machine and same app server
<5> but
<6> okay. So the "remote" bean - the session bean - accesses an entity bean via the java:comp/env/ namespace, which maps to a local entity bean.
<5> well, that's just it. it doesn't seem as if the sun deploy tool allows you to bind a local bean to JNDI
<6> it doesn't have a choice, really :)
<5> why
<6> because it's spec-mandated
<5> which spec, j2ee ?
<6> yep
<5> the j2ee spec says that you can't bind local beans to jndi?
<6> no, the spec mandates the opposite
<6> it doesn't have a choice but allow you to bind things
<5> odd ... so why can't i do it?
<6> Dunno
<5> eh
<5> who cares anyways ... from what i udnerstand usuing the local interfaces are meant for special cases anyways
<4> jdbc question; If I create a statement with Statement stmt = conn.createStatement(), can I issue any number of executeQuery()s against it or will garabge accumulate?
<6> whodis: well, if you're using entity beans, you want local access :)
<6> Zeekius: garbage will always accumulate
<4> accumulate as in somewhere references are maintained until the statement close()s that is...
<6> Zeekius: nah, that's not a problem
<4> I am cautious because a ResultSet/PreparedStatement/Statement thing has been a memory issue...
<6> if it has, you've been working under some SERIOUS constraints
<6> or doing some things you shouldn't have been doing
<4> well, it is more of a issue of executable size going from 50m to 90m to heap memory errors; explicit Statement/PreparedStatement/ResultSet close()es fixed it...
<6> well, that's wise in any case
<6> when you're done with a resource, you should close it
<4> true, so I guess the question is, then: after you finial with the resultset of a statement's executeQuery(), is there any other close()/finalizing actions you should (in good practice) perform before the using the statement to do another executeQuery() (other than closing the ResultSet)?
<4> (finial=finish)
<6> close the resultset, yes
<6> although... what environment are you doing this in?
<4> M$, mysql
<4> it is a polling loop, never exits method
<6> j2ee or j2se?
<6> and that sounds horrible, you shouldn't use a DB in a loop like that
<0> use the addBatch() method
<0> and set it to null when you are done
<6> um
<4> eh< never seen addBatch
<0> if you are executing SQL statements in succession then that's what it's for
<0> when you are done..do a .close() then set the object to null
<4> another app is adding records to a database, using a sequential key. We periodically check for new records posted (comparing latest key to what we have recorded) to see if there is new data for us to gleen. s
<6> Zeekius: sounds like you should be using a message queue, not a database
<4> Wonderous non java legacy app filling the database.
<6> so?
<6> message queues aren't java-specific
<4> So: no code changes on the poster. *some* thread in our app needs to read the database...
<4> I have not seen a jdbc interface to auto-detect new records on a table...
<0> so you just hit it a gazilion times a day to see nice
<4> 'to see nice'?
<0> to see, nice.
<6> Zeekius: there isn't one, although you could install a trigger on the table to notify your program
<6> and that would be much smarter :)
<4> Sadly, cannot touch that database either. This is fairly efficient, since we only poll like once every thirty seconds, so we get back a full resultset
<4> Wish there was a more integrated way, but not with allowances (allowances on other app/db = 0)
<6> Zeekius: so you query for new records only?
<4> Yeah, select where the id > last polled id
<6> small resultsets then
<6> so if you have a performance/garbage problem, you're doing something very strange
<6> but every 30 seconds... gosh, I'd just close the entire connection every time
<0> or maybe thread it
<6> why thread it? It shouldn't live long enough to need threads
<0> well he seems to be having performance issues dunno
<4> We only need 1 thread to read em. Seems stupid to do a timered thread to kick off 1 instance when you can do the same in a loop.
<6> threads would only increase them
<0> the OS can handle thread easier..just a thought
<6> well
<6> there are lots of issues there
<4> Quantified issue was related to different methods. I am working thru all jdbc related code to make sure resources are handled properly
<6> for a polling app, unless the polls take longer than the poll period, you'd have no reason for threads and, given what he said about what his perf problems were, threads would increase the problem
<6> but then again, that's armchair analysis
<4> And yes, there can be quite a few records coming back on a single resultset actually.
<0> i thought if it were in a different thread that the jvm might be more willing to close statements, connections
<0> and that seems to be his problem
<4> I am not trusting it to close anything anymore, thus wanting to make sure I have explicit closes where I can, actually.
<0> but you do need to make sure you are properly closing and setting them to null for sure
<4> trusting the jvm in the other methods is what got me in the first place...
<0> well if you can't find it then you prolly want to profile it
<7> any recomendations on good .jsp books for a newbie?
<7> either someone can recommend a book... or i will be forced to come ask for help every 10 minutes using broken english while not paying attention to the answers you are giving
<7> it's your choice
<7> ;)
<8> that kind of attitude is bound to get you ignorance.
<0> hahaha
<0> why don't you just use the book of google?
<7> i have found it easier to have a book reference guild when learning a new language
<7> just my personal preference
<0> i'd suggest learning java first before jsp
<9> hehe
<7> i sort of know java.. well, not really... i understand the structure and everything
<7> the big motivation for me in learning is practical use... i have practical use for jsp, but not java...
<8> jsp is java.
<8> Java ServerPages.
<7> i know this
<8> do you really?
<0> that's utterly ridiculous
<0> use javascript then
<7> so no recommendations?
<0> kuruption we are telling you what ALL the books are going to tell you...learn java first or you'll be lost
<8> well, I think sabre's suggestion is a very good one. Once you got there you could start using <% <javacode> %>.
<8> Then work your way up (if needed) with regards to taglibs. Simple.
<0> i'd ask you what your "practical use" is but i gotta go to a meeting, hasta
<8> sabre: *wave*, have a good one!
<2> Re hi
<7> okay, so then, any good books on java?
<8> the java tutorial is a good place to start. http://java.sun.com/docs/books/tutorial/. And then another good one is "Thinking in Java", also freely available.
<10> Can some one plz explain the following line to me "System.out.printf( "Integer = %d, Squared = %d\n", i, i*i );"
<7> printing out text?
<7> heh
<8> KB***: put it in a small program and run it. You'll see soon enough.
<10> well i kinda figured that and i know what it does i just wanted to get the syntax of how it works never used formatted prinf methode before
<7> oh
<7> best way to explain it would be using C's printf man page
<8> KB***: thats where the API documentation comes in. Check the PrintStream cl*** for that.
<8> kuruption: don't be silly.
<7> or sprintf
<8> kuruption: this has absolutely /nothing/ to do with C.
<8> java.io.PrintStream has a printf method.
<7> printf() is a function that, as far as i know, originally comes from C
<8> kuruption: <sigh>
<7> and im pretty sure printf() was added to java to replicate the C functionality
<7> someone at Sun just didn't go "oh hey what a great function to add"
<8> kuruption: for someone who just asked for a place where to learn Java I think thats a stupid comment.
<7> so you're saying that printf() does *not* come from C?
<7> that although the syntax is exactly the same... that it works exactly the same.... there is absolutely no correlation?
<7> give me a break
<10> ehh i'll leave you two alone :) haha i never learned it in C either
<8> kuruption: You know, the option to actually put characters and such comes from the ***embly language. You know; putting values in the video memories place. Does this mean every programming language is related to it in such a way that you'd need to know about it ?
<8> kuruption: get real.
<7> i may be new to java, but i can program several other languages all of which have a printf() function...
<8> KB***: no need, I'm not wasting more time on sillyness like that.
<8> KB***: what you need is the API documentation for whatever JVM you're using and simply look up the java.io.PrintStream cl***. That will explain all there is to know about printf.
<7> yes, YES it does... every language is related in some ways
Return to
#java
or
Go to some related
logs:
#MissKitten
#linux
xen resize imagefile
spanish characters + collate + mysql
#php
client denied by server configuration: /usr/local/apache2/htdocs/favicon.ico
#squid
par la cur
xorta wow
#AllNiteCafe
|
|