Estou tendo um probleminha de marinheiro de primeira viajem… 8)
Quero que o meu SessionBEan retorne um resulset do banco de dados , mas ao retornar para o cliente obtenho um
“ResultSet IS NOT SERIALIZABLE OBJECT” :shock: :shock:
ok , ok… eu teria que jogar tudo dentro de uma collection e retornar… mas a pergunta eh:
Soh existe esta solucao ? 
Nao existe nada que serialize um resultset por ae ? 
Obrigado…
ResultSet depedende da conexão para existir, logo não é serializável.
Cara, para que diabos você quer fazer isso? Ficar passeando pra lá e pra cá com esse custoso resultset?
hehehe
pense um pouco juntamente comigo…
tenho um objeto EJB no Jboss chamado PESSOA e este objeto eh um SessionBean stateless , otimo… este PESSOA tem um metodo
.getPessoasComUnhasEncravadas(); :lol:
e ele retorna todas as pessoas do banco de dados que tem “as unhas encravadas” , otimo… sao 215 campos :shock: nessa tabela pessoa
ae , no meu CLIENT eu INVOCO o objeto PESSOA e quero saber quantas pessoas tem unhas encravadas pra jogar num JTable esssa informacao…
Como passar isso do servidor para o Cliente se nao por um ResultSet ? :?:
Que tal atraves de um List?
[quote=leonardom]
Que tal atraves de um List?[/quote]
E o overload disso aonde fica ?
antes meu client pegava o resultset que jah eh uma especie de List devolvida do banco de dados…
agora tenho q passar de um resultset pra um arraylist e dae sim passar para o cliente ? vc nao acha isso meio redundante nao ?
será possivel que esta eh a unica solucao ?
Overload? 
[quote=chun]antes meu client pegava o resultset que jah eh uma especie de List devolvida do banco de dados…
agora tenho q passar de um resultset pra um arraylist e dae sim passar para o cliente ? vc nao acha isso meio redundante nao ?
será possivel que esta eh a unica solucao ?[/quote]
Ai eh que esta. O ResultSet NAO eh uma “especie de lista”. http://java.sun.com/j2se/1.4.2/docs/api/java/sql/ResultSet.html
Alem disso, mesmo que nao houvesse processamento remoto, essa eh uma maneira melhor de se fazer isso. Ou voce vai propagando o ResultSet ate chegar na view e entao exibe os dados diretamente dele? Onde estao as tuas classes?
Marcio Kuchma
Hum, não sei se alguma implementação de RowSet (não ResultSet) é Serializable. Pelo que me lembrava a intenção é que ele fosse como o “disconnected recordset” do ADO para algumas aplicações.
[quote]
Ai eh que esta. O ResultSet NAO eh uma “especie de lista”. http://java.sun.com/j2se/1.4.2/docs/api/java/sql/ResultSet.html
Alem disso, mesmo que nao houvesse processamento remoto, essa eh uma maneira melhor de se fazer isso. Ou voce vai propagando o ResultSet ate chegar na view e entao exibe os dados diretamente dele? Onde estao as tuas classes?
Marcio Kuchma[/quote]
vamos lah… performance… eu soh quero por num jtable… a pergunta que ninguem me respondeu… soh atraz desse overload TODO ( receber num Resultset no servidor , passar pra um Arraylist tudo denovo e ae voltar pro cliente um arraylist ) eh que vou conseguir exibir num jtable o resultado simples de um “select * from table where unhasescravadas = ‘true’” ?
Eh apenas um sim , ou um nao… se tiver outras formas , eu vou preferir outras formas… prq desta forma gera overload demais… overhead de protocolo , nao imagino 1 estacao fazendo isso imasgino 100 , nao tenho ideia da escalabilidade e performance do EJB , isto que esta me assustando …
alguem que trabalhe com JBOSS pode me dizer a sua experiencia ? em questoes de desenpenho , config de processador etc…
[quote=thingol]Hum, não sei se alguma implementação de RowSet (não ResultSet) é Serializable. Pelo que me lembrava a intenção é que ele fosse como o “disconnected recordset” do ADO para algumas aplicações.
[/quote]
JavaTM 2 Platform Std. Ed. v1.4.2
javax.sql
Interface RowSet
public interface RowSet
extends ResultSet
A rowset eh uma interface extendidade de Resultset…
Nunca vi outra solução, na verdade utilizo o hibernate e ele faz exatamente isto… A performance é satisfatória…
Na verdade, mesmo se eu pudesse passar o recordset diretamente para o cliente, eu não o faria. O principal motivo é que quero que meus resultados saiam do DAO diretamente em forma de objeto, por exemplo se pesquisei por pessoas eu quero uma lista de pessoas e não um recordset onde pego cada campo da tabela…
Espero ter ajudado de alguma forma!!!
Fallow
[quote=TedLoprao]Nunca vi outra solução, na verdade utilizo o hibernate e ele faz exatamente isto… A performance é satisfatória…
Na verdade, mesmo se eu pudesse passar o recordset diretamente para o cliente, eu não o faria. O principal motivo é que quero que meus resultados saiam do DAO diretamente em forma de objeto, por exemplo se pesquisei por pessoas eu quero uma lista de pessoas e não um recordset onde pego cada campo da tabela…
Espero ter ajudado de alguma forma!!!
Fallow[/quote]
Entendi exatamente o que vc quer dizer… mas me responda a pergunta…
se for SOH pra exibir em tela os dados de um recordset … o que eh mais rapido ? gerar um array de objetos pessoa e passar ou passar o recordset diretamente ?
Somente neste caso.
Hmmm, vc está pesando apenas uma váriavel, rapidez… (na minha opinião essa não deve ser a única medida a ser considerada)…
Mas respondendo sua pergunta, ao meu ver a resposta é depende… Lembre-se q a implementação do ResultSet depende do responsável pelo driver jdbc, logo não sei como cada fabricante (ou desenvolvedor) trata a ligação entre o ResultSet e o banco… Teoricamente seria mais rápido, mas vai saber :lol: !!
Ps.: Acredito ainda que o meu DAO não deveria saber se eu quero aqueles dados para exibir em uma lista ou seja lá o q for, ele deveria me retornar a lista de pessoas da mesma maneira!!
Fallow
Acho q a questao nao seria “O Q EH MAIS CORRETO” ?
Nao eh legal passar um RS para seu cliente e pronto .
Qt a performace, provavelmente passar o RS para o cliente seja mais rapido ( embora acredito q nao seja possivel, pois o mesmo nao eh serializavel alem de horrivel ). Alem disso, sua tela teria q saber “trabalhar” com RS, alem de ter q tratar possiveis erros de DB!! Bobeira neh… Vamos deixar esta responsabilidade para o EJB e dar a tela seu papel real… Mostar dados
chun, você está falando que vai prejudicar a performance … já testou isso? Não? Então por que não testa e coloca o resultado aqui para a gente?
Caro mesmo é criar e manter um resultset, não uma lista.
E sugiro a mesma coisa que o sr. Aloprão. Conceitos de orientação a objetos e separação de camadas não servem só para deixar o projeto bonito cara.
E meus profundos pêsames por ter que trabalhar com uma tabela com 250 colunas hehe
[quote=LIPE]chun, você está falando que vai prejudicar a performance … já testou isso? Não? Então por que não testa e coloca o resultado aqui para a gente?
Caro mesmo é criar e manter um resultset, não uma lista.
E sugiro a mesma coisa que o sr. Aloprão. Conceitos de orientação a objetos e separação de camadas não servem só para deixar o projeto bonito cara.
E meus profundos pêsames por ter que trabalhar com uma tabela com 250 colunas hehe[/quote]
Sinceramente ? jah testei… e fica 30% mais lento… isso com 1 cliente… fico imaginando com varios ( P IV 2.8 768 de ram ) , estou vindo de uma plataforma windows… estou coordenando a transicao DELPHI->JAVA , tenho que ter argumentos… “que eh o correto” eu sei…
A orientacao a objetos eh linda… mas em certos casos essas imposicoes nao sao bem vindas em uma “transicao de conhecimentos” , estou tentando fazer da maneira mais tranquila possivel …
Quanto aos 250 campos… tem tabelas que sao necessarios , ou teria que quebrar em 4 ou 6 tabelas linkando pelo ID , isso nao seria muito “elegante” , para dar suporte seria um saco… prq teria que ficar percorrendo id de tabela em tabela… e vc sabe como eh suporte tecnico… pensa BEm diferente…
mas estou estudando o CachedRowSet do JDK 1.5 , fazendo testes com ele no jboss… vamos ver… ele se propem a fazer isto…
" a disconnected ResultSet " , em algumas vezes isso eh necessario… e nao adianda esperniar… ateh a Sun viu isso
class com.sun.rowset.CachedRowSetImpl
coordenar eh uma tarefa dificil , nao eh apenas falar “faca…” e sim “faca desse jeito prq eu tenho certeza do que estou falando”
Ah, era isso mesmo, CachedRowSet, não estava me lembrando dele (tinha visto isso em uma palestra, depois esqueci o nome certo. Além do mais eu tinha feito um htmlhelp do javadoc do J2EE 1.2, para facilitar o meu serviço - e forçar-me a usar apenas essas APIs velhas, para rodar naquele ambiente horrível do iPlanet, e não atualizei o htmlhelp para J2EE 1.4… )
Acho que um “disconnected recordset” muitas vezes é interessante (principalmente se você está acostumado a trabalhar no ambiente Micro$oft…) Mas o padrão é usar algo como Hibernate, ou pior, fazer as coisas no braço (como se vê muito por aí).
Otimo… finalizado os testes…
o CachedRowSet do JDK 1.5 juntamente com o JBoss resultaram em uma performace 2% inferior ao select puramente passado…
Acredito que quem encontre este topic precisa saber que existe uma forma feita pela propria Sun…
este CachedRowSet funciona como um “disconected resultset” , carrega consigo desde informacoes sobre METADATA até os registro propriamente ditos , muito legal mesmo… mas por se tratar de uma interface , precisa de uma implementacao … a Sun fez uma implementacao ( o qual ela nao disponibiliza no codigo fonte ) do CachedRowSet , se chama ChachedRowSetImpl … veja como eh facil…
…
ResultSet rs;
Statement st;
rs = st.execute(“select * from table”);
com.sun.rowset.ChachedRowSetImpl crs = new com.sun.rowset.ChachedRowSetImpl();
crs.populate(rs);
return crs;
funciona perfeitamente…
Obrigado aos que responderam a esta indagacao , muito obrigado mesmo.
Meu deus… que gafe… falei merda…
o CachedRowSetImpl esta presente na 1.5 por padrao , mas se vc usa a 1.4 pode baixar da sun:
Desculpe a gafe
Não sei não, mas acho que esse populate pega os resultados e preenche uma Collection como se tu fizesse na mão…
Esses testes que tu fizeste para concluir essa distância tão gritante de resultados (2% e 30%), como foram feitos??
Fallow