Ei povo, queria saber com vcs q tem mais experiencia c uso de RMI, geralmente qnd se usa RMI, vc usa “synchronized” nos metodos do obejto remoto??? Pq, por exemplo, multiplas pessoas acessando um banco, atraves de objetos remotos c/ RMI, eu vejo a necessidade deste controle, para q estes multiplos acessos n interfiram uns nos outros, entao axo q c synchronized nos metodos arrumaria isso. E ai, usam??? O RMI ja trata isso??? Como acontece??? Fiquei c/ esta duvida.
O RMI não trata isso. Só você pode salvar seus métodos de problemas clássicos de IPC.
Use synchronized nos seus métodos da mesma forma (com os mesmos conceitos) que você usa em programação não-distribuída.
duvida besta: p usar synchronized, eu preciso usar threads p/ chamar os metodos syncronizados ou posso chamar ele diretamente sem estarem em 1 thread? posso chamar direto ne?
hein?
Pode.
Um método synchronized não é cú doce.
O fato deste rapaz ser synchronized não quer dizer que aplicações monothread não possam chamá-lo.
Ok?
eh pq eu so vejo exemplo de syncrhonized c threads pelo google.
mas assim, quer dizer q eu posso ter o seguinte codigo:
class Teste {
....
public synchronized void fazAlgo ();
...
}ai eu uso o objeto sem estar dentro de uma thread e ele ira realizar exlcusao mutua ne isso?
public static void main (String[] args) {
Teste obj = new Teste();
// isto aki n precisa ta dentro de uma thread e vai fazer exclsao mutua, ne isso?
obj.fazAlgo();
}confere?
obs: to batendo nesta tecla pq fikei c duvida gerals.
hein cocota, eh isto?
hlds,
Mude um pouco seu discurso. Não diga que o objeto está dentro de uma Thread.
A dica é que você leia um pouco mais sobre o conceito de Threads (geralmente apresentado em livros de Sistemas Operacionais) e você aumentará muito seu conhecimento sobre programação concorrente.
Tu podes usar synchronized num programa monothread. Como eu já disse acima. Ele vai estar protegido contra nada, mas vai estar protegido.
usar synchronized é uma facilidade da linguagem JAVA. O estudo de threads vai lhe mostrar que na verdade esse modificador está por trás do conceito de MONITORES. Que na minha opinião, são perfeitos. Se fodam os semáforos.
Leia, vc vai entender.
www.submarino.com.br
e compre o Sistemas Operacionais Modernos de Andrew Tanenbaum.
É um dos poucos livros que eu comprei, porque é bom.
pow vei eu ja li p kct sobre threads, so q fikei c esta pekena confusao, dx ve se esclareco rapidin, p n restar duvidas: como eu disse os exemplos c synchronized q vi, eles estavam sendos usados em paralelo c threads, executando a exlcusao mutua, dai eu keria saber se p implementar esta exclusao era obrigatorio usar threads em paralelo ou se um programa “monothread”, como vc se referiu, poderia usar objetos sincronizados (sem usar threads explicitamente) e executar exclusao mutua, esclareceu?
esclaresceu.
Pode sim. Não vai ter nenhum problema aparente se você usar synchronized em todos os métodos que você fizer na sua vida.
Mas faça isso não… 
eu to ligado q metodos synchronized sao relativamente 10 vezes mais lentos q os nromais, mas tem casos q n tem p onde correr 
numa app distribuida em rede, usando rmi, e tendo um servidor q ficará responsável por enviar os dados do banco p os cliente remotos na rede, seria interessante usar synchronized nos metodos do servidor q acessam o banco (metodos d adicao, remoca, exibicao dos dados do banco) ? eu poderia n colocar sem ter problemas c ipc? (pelo q pensei, axo q n seria obrigado colocar, mas nunca testei algo do tipo, e ai?)
Aí o problema aumenta.
Transação.
Você além de proteger seus métodos, vai ter que proteger a transação. Tá ligado nesse conceito?
q eu saiba, transacoes, eh a movimentacao do banco (selects, insets, updates, deletes), eh este o conceito?
tem certeza q precisa de synchronized nesta app q farei, pq pelo q pensei so poderiamos ter problema tipo: 1 insert atrasa em relacao a 1 select, dai n ira exibir o dado do insert q se atrasou, mas n vejo problemas graves qto a isto, ou estou enganado? existe algum outro problema a mais?
Não vejo nenhum problema adcional, o que você está dizendo é relevante, mas não se encaixa no problema das transações.
E também não vejo necessidade de usar synchronized.
‘Transações’ é basicamente isso que você tá pensando. Entretanto você teria que cuidar para que as operações de banco fossem REALMENTE feitas e numa sequência definida.
É um conceito mais abrangente que isso. Mas pense no seguinte caso:
Digamos que você tem clientes cadastrados num SGBD, e que esses clientes podem realizar pedidos que também estão cadastrados nesse SGBD, os pedidos são compostos de itens. Um cliente pode realizar vários pedidos, e um pedido pode ser feito por vários clientes.
Exemplo:
João fez um pedido. (get na PK de joão)
O pedido era composto de 2 livros e uma bola. (get na PK dos itens)
Grava-se os itens do pedido (INSERT INTO pedido_has_itens)
Grava-se o pedido (INSERT INTO pedido)
Grava-se o pedido do cliente (INSERT INTO cliente_has_pedido)
Você concorda que ao realizar o pedido de joão, teremos que fazer mais de um INSERT? E se no meio de um dos INSERTs a conexão fosse perdida? Teríamos um pedido inserido no banco sem itens? sem cliente? e quem garante que foi feito pelomenos o primeiro passo?
Aí vem a transação.
A transação se inicia num determinado ponto chamado de início (begin) e se desenrola até o fim. Na ocorrência de um erro, existe o Rollback, que desfaz tudo que foi feito até o ponto início. Caso nenhum erro ocorra, é chamado o Commit que efetivamente salva tudo no banco.
Eu to ligado no q vc quis dizer, mas axo q no meu dominio de problema isto n ira acontecer. Neste teu caso, este controle de dar rollback ou commit, seria feito no servidor ou no cliente? Como seria uma possivel solucao disto?
Nunca ouvi falar de controle transacional no cliente.
E no Servidor, você pode fazer isso em dois lugares:
- No Banco
- Na Aplicação
Pelo jeito, no andar da carruagem desta conversa, sua aplicação não vai precisar nem de controle transacional nem de monitores para objetos.
faça o normal mesmo!
