[JAVA6]oggetto di "dimensione fissa"

[Frank1962]

premetto, penso sia un'opzione particolarmente utile ...avere la possibilità di creare un contenitore di oggetti "limitato" nell'utilizzo della memoria permette al programmatore di capire quanti oggetti di un certo tipo può istanziare prima che il sistema vada in crisi di memoria centrale

[PGI-Bis]

Potresti usare un anello. Una cosa tipo:

public class Ring<T extends Serializable> {

    public T push(T value)...

    public T extract()..
}

Per realizzare il contratto di Ring crei un buffer di dimensione nota. Al push(value) serializzi value nel buffer. Per extract deserializzi.

Se l'anello è pieno, push restituisce il record rimosso per far posto a value. Se intendi scartare le richieste più vecchie crei un anello LIFO. Altrimenti un FIFO.

A naso, non dovrebbe essere complicato.

[Frank1962]

si maaaahhh ....un momento!! ...mi stai consigliando di serializzare/deserializzare per l'implementazione?
Questo che voglio fare è rivolto sopratutto al lato prestazione, cioè il non dover scrivere ogni volta sul db la request del client: se mi consigli di serializzare/deserializzare su buffer mi sa che allora mi conviene direttamente scrivere sul db....

poi non so, magari dalla java 6 la serializzazione è diventata iperveloce....

[PGI-Bis]

Devi fare un test per verificare se una soluzione è compatibile con gli obiettivi di performance dell'applicazione che stai sviluppando.

Io ho fatto una prova con questa classe:

package serialtest;

import java.io.*;

public class Query implements Serializable {
	private static final long serialVersionUID = 0;
	private String path;
	private long timestamp;

	public Query(String path, long timestamp) {
		this.path = path;
		this.timestamp = timestamp;
	}

	public String getPath() {
		return path;
	}

	public long getTimestamp() {
		return timestamp;
	}

	private void writeObject(ObjectOutputStream out) throws IOException {
		out.defaultWriteObject();
	}

	private void readObject(ObjectInputStream in) throws IOException {
		try {
			in.defaultReadObject();
		} catch(ClassNotFoundException ex) {
			throw new IOException("Class not found...");
		}
	}
}

E me la sputa in un ByteArrayOutputStream a poco più di 77.000 istanze al secondo (stringa random di 204 caratteri). Supponiamo che il tempo di deserializzazione sia analogo. Supponiamo inoltre che la macchina di test sia simile a quella di esecuzione.

A questo punto uno deve valutare se 0.013 millisecondi per scrivere e leggere una query con il meccanismo della serializzazione standard siano eccessivi rispetto ad un'altra opzione.

Nota che qui la questione non è se la serializzazione sia o non sia rapida. Anche se impiegasse l'ora e un quarto a cui generalmente si pensa, quest'ora e un quarto andrebbe valutata nel contesto dei requisiti del programma.

[Frank1962]

i requisti del programma, di solito, sono la massima velocità di esecuzione della query ...nel mio caso essendo il webserver volto a soddisfare le richieste dei client non vorrei, essendoci in mezzo questo salvataggio della richiesta, un eccessivo overhead prima che si passi alla fase di risposta alla GET/POST ....considerando che siamo in un contesto di un webserver che deve gestire parecchi client contemporanemente potrei vedermi crollare le prestazioni proprio per questo eccessivo (forse quasi oserei dire, pedante) salvataggio di tutte le richieste perventure al server.....

Dal tuo codice però non capisco una cosa, la defaultReadObject() legge l'oggetto dallo stream passato come argomento, ma perchè il metodo non ritorna l'oggetto appena deserializzato?

ps: ma i 0.013s li hai messi a caso? ...perchè considerando le 77000 istanze al secondo e ponendo il tempo di deserializzazione equivalente a quello di serializzazione abbiamo 1s/(77000/2) che è mooolto più basso di 13ms....

[PGI-Bis]

ps: ma i 0.013s li hai messi a caso?

Be', no. Ho scritto "millisecondi" e non "secondi".

Invece è ambiguo quando scrivo

Originariamente inviato da me stesso

...se 0.013 millisecondi per scrivere e leggere...

Qui intendevo "...se 0.013 millisecondi per scrivere e 0.013 millisecondi per leggere..."

Per questo ho detto 0.013 e non 0.026.

Il meccanismo tramite cui è realizzata la (de)serializzazione standard non restituisce l'oggetto deserializzato ma, in un certo senso, "riempie un'istanza vuota". Tale istanza è poi usata come valore restituito dal metodo readObject() di ObjectInput.

[Frank1962]

Originariamente inviato da PGI-Bis

Be', no. Ho scritto "millisecondi" e non "secondi".

opss ...una piccola svista
in effetti, però, non sapevo che un elaboratore avesse una precisione dell'ordine del milionesimo di secondo!
Interessante la possibilità di serializzare/deserializzare un oggetto in quel modo ...ma l'ObjectInputStream e l'ObjectOutputStream fanno le veci del "database" in memoria? ..cioè se vado a serializzare più oggetti dello stesso tipo in quegli stream il distinguo nell'andarli a deserializzare viene eseguito automaticamente? a prima vista da come hai scritto il codice sembrerebbe proprio di si

[PGI-Bis]

Non so se il comune hardware offra una precisione al milionesimo di secondo. So che il timer che Java usa per nanoTime() ha una granularità massima di 1 millisecondo. Io ho fatto un test su 50000 serializzazioni e ho diviso il tempo totale per il numero di istanza serializzate, ottenendo il valore medio che ho indicato.

Quanto alla distinzione automatica se intendo correttamente il dubbio la risposta è sì. Cioè se scrivo 3 oggetti distinti posso poi leggere distintamente questi stessi 3 oggetti.

[Frank1962]

Originariamente inviato da PGI-Bis

Quanto alla distinzione automatica se intendo correttamente il dubbio la risposta è sì. Cioè se scrivo 3 oggetti distinti posso poi leggere distintamente questi stessi 3 oggetti.

ma quindi questo vuol dire che l'ObjectInputStream deve essere in qualche modo "collegato" all'ObjectOutputStream ...cioè dove scrivo poi e dove dovrò andare a leggere, o sbaglio? ...e in questo caso come faccio a collegate un outputstream a un inputstream che si appoggiano a un bytearrayinputstream/outputstream?
oltretutto, come mai i metodi write/readObject della classe Query sono private?

[PGI-Bis]

Mhhh...

Hai presente quando scrivi un testo su un file? Ecco, se vuoi avere indietro quel testo devi leggere lo stesso file.

Se il testo è "pippo" e sul file scrivo prima la p, poi la i, poi la p eccetera, per leggerlo io devo leggere prima la p, poi la i, poi la p eccetera.

Questo è il collegamento che deve sussistere anche tra ObjectOutput e ObjectInput.

Quanto all'output-input che si collega al byte array... la metti giù un po' troppo complicata.

Tu serializzi l'oggetto in memoria e lo deserializzi leggendo dei byte dalla regione di memoria in cui li hai scritti.

I metodi readObject e writeObject sono private perchè chi ha progettato il meccanismo della serializzazione standard ha voluto esprimere il vincolo "non invocate direttamente questi metodi, grazie".

[Frank1962]

Originariamente inviato da PGI-Bis

Mhhh...
Se il testo è "pippo" e sul file scrivo prima la p, poi la i, poi la p eccetera, per leggerlo io devo leggere prima la p, poi la i, poi la p eccetera.

suppongo che intendi l'accesso in modalità fifo? .....io pensavo invece che, dato un oggetto serializzabile, passandogli a un metodo xyz uno stream lui vi si serializzasse e si occupasse di recuperare tutte le informazioni necessarie in un secondo momento alla chiamata di un determinato metodo zyx.
Con la modalità fifo sono invece obbligato a leggermi tutti gli oggetti serializzati prima di ottenere quello voluto!

Query q1 = new Query("ciao",1234567890);
Query q2 = new Query("hello",1234567890);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
try {
  ObjectOutputStream oos = new ObjectOutputStream(baos);
  oos.writeObject(q1);
  oos.writeObject(q2);
  ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray());
  ObjectInputStream ois = new ObjectInputStream(bais);
  q1 = (Query)ois.readObject();
  q2 = (Query)ois.readObject();
  System.out.println(q2.getPath());
} catch (Exception e) {
  e.printStackTrace();
}

...e se volessi deserializzare q2 senza serializzarmi q1?

a me piacerebbe invece fare un'utopia simile () :

Query q1 = new Query("ciao",1234567890);
Query q2 = new Query("hello",1234567890);
DatabaseInMemoriaCentraleConUnNomeTroppoLungo dbmem = new DatabaseInMemoriaCentraleConUnNomeTroppoLungo(10YottaByte);
q1.miserializzo(dbmem);
q2.miserializzo(dbmem);
Query q1= q1.mideserializzo(dbmem);
System.out.println(q1.stampalostampabile());

[PGI-Bis]

Se devi creare un buffer per un servizio che evade delle richieste avrai una politica di ordinamento delle evasioni che si riflette nell'accodamento delle richieste. Se la politica di evasione richiede un accesso casuale, tu crei un buffer ad accesso casuale. Se è richiesto un accesso lifo, crei un buffer lifo. Se è richiesto un accesso fifo, crei un buffer fifo.

Se il server evade le richieste un po' come gli gira e un po' come tira il vento allora non è più un problema di programmazione. Può essere poesia o pittura o una qualsiasi altra nobilissima e affascinante attività creativa dell'uomo. Ma non è programmazione.

La serializzazione si occupa di trasformare un oggetto in un pacchetto di byte e la deserializzazione di trasformare un pacchetto di byte in un oggetto.

Le specifiche del programma che devi creare le conosci tu e tu devi decidere se la serializzazione sia o non sia idonea a rappresentare la soluzione ad uno dei problemi che hai già risolto.

E' possibile che io mi sbagli, perchè si tratta pur sempre di una conversazione astratta su questioni delineate a botta e risposta su un forum, ma ho l'impressione che tu abbia il problema ma non la sua soluzione.

La programmazione è l'attività di rappresentazione della soluzione ad un problema. Non è un tecnica di soluzione di problemi.

Devi già sapere quello che devi fare. Poi prendi gli strumenti offerti dalla piattaforma di programmazione che hai scelto e li usi per rappresentare, per tradurre quello che già sai di dover fare.

Io ti parlo di serializzazione perchè la soluzione che ho trovato al problema che hai proposto è rappresentabile con questo strumento. Pensavo che la mia soluzione coincidesse con la tua ma ora mi viene il dubbio che, nel nostro dialogo, la mia soluzione sia anche l'unica in ballo

[Frank1962]

ammetto che forse la strada al "contratto" che la discussione originariamente voleva condurci si è andata un pò a perdere ...ma in realtà il problema è sempre stato quello: capire quanto un oggetto o una collezione di oggetti occupa in memoria centrale.
Se la serializzazione in un bytearrayoutputstream mi permette di far ciò: ben venga!
Il problema è che non vorrei che questa soluzione mi portasse fuoristrada sotto due aspetti: lato prestazione e lato "usabilità" di quello che voglio creare.
Se dal lato prestazioni abbiamo visto che ciò conviene dal lato usabilità rimango con qualche perplessità; ovvero: se voglio recupare l'oggetto di indice i dalla sfilza di oggetti che inserisco nel mio dbase come cavolaccio faccio se non applico qualche paradigma in chiave poetica/pittorica di influenza ermetista ....o per meglio intenderci ( ) ogni volta che serializzo UN oggetto devo prendere il singolo byte[] contenente i byte dell'oggetto e inserirlo in una hashmap per riuscire a creare una sorta di accesso indicizzato?
Il dubbio/perplessità/confusione veniva dal fatto che pensavo la serializzazione avese bultin la possibilità di fare il distinguo (tramite un suo protocollo) degli oggetti serializzati all'interno di un'area di memoria (in questo caso il nostro bytearrayoutputstream).

[Frank1962]

ecco una prima implementazione ....a voi il giudizio!! (sopratutto per pgi, essendo ormai nato un "contenzioso" tra un nobilissimo programmatore java (pgi) e un lurker con un attacco mistico di posting (frank) )

import java.io.*;
import java.util.HashMap;

  

public class ObjectDBase {
    
    private int mode = 0;
    private int total = 0;
    private int maxsize = 0;
    private Queue q = new Queue();
    private HashMap<Integer,Object> hm = null;
    private ByteArrayOutputStream baos = null;
    private ObjectOutputStream oos = null;
	
    ObjectDBase(int maxsize, int mode) {
	this.mode = mode;
	this.maxsize = maxsize;
	hm = new HashMap<Integer,Object>();
	try {
	    baos = new ByteArrayOutputStream();
	    oos = new ObjectOutputStream(baos);
	} catch (IOException e) {
	    e.printStackTrace();
	}
    }
    
    public void addObject(int key, Object o) throws Exception {
	baos.reset();
	oos.reset();
	oos.writeObject(o);
	byte[] aux = baos.toByteArray();
	if(!(total+aux.length>maxsize)) {
	    insertObject(key, aux);
	} else {
	    if(mode==0 || aux.length>maxsize) {
		throw new Exception("spazio insufficente");
	    } else {
		while(total+aux.length>maxsize) {
		    Integer inx = (Integer)q.deQueue();
		    byte[] a = (byte[])hm.get(inx.intValue());
		    total -= a.length;
		    hm.remove(inx);
		}
		insertObject(key, aux);
	    }
	}
    }
    
    private void insertObject(int key, byte[] array) {
	hm.put(key, array);
	q.enQueue(key);
	total += array.length;
	System.out.println(total);
    }
     
    public Object getObject(int key) {
	byte[] aux = (byte[])hm.get(key);
	ByteArrayInputStream bais = new ByteArrayInputStream(aux);
	try {
	    ObjectInputStream ois = new ObjectInputStream(bais);
	    return ois.readObject();
	} catch (Exception e) {
	    e.printStackTrace();
	}
	return null;
    }

}

il main per testarla:

public static void main(String... args) {
  try {
    int i = 0;
    while(true) {
      i++;
      odb.addObject(i, buildmap());
    }
  } catch (Exception e1) {
    e1.printStackTrace();
  }

  public Map buildmap() {
    HashMap map = new HashMap();
    int i = 0;
    while(i<(int)100.0*Math.random()) {
      map.put(i, Math.random());
      i++;
    }
    return map;
  }
}

dove Queue è un'implementazione di una semplicissima collezione in modalità fifo ....la utilizzo per ricordarmi quali sono state le prima chiavi inserite in modo tale sa sapere quali oggetti dovrò rimuovere dall'hashmap nell'eventualità che lo spazio si esaurisca.
Mi sorge un problema sul fatto della compressione dei dati ...ho provato a utilizzare il normale deflater fornito dalle librerie java ma ho notato che la dimensione dei dati compressi molte volte tende a superare la dimensione dei dati originali (per piccole quantità di dati, dell'ordine di una stringa di 200/300 caratteri) quindi mi chiedo se ci può essere qualche alternativa che non vadi a salvare ogni volta il dizionario nei dati di compressione.

[PGI-Bis]

Ma che nobiltà, eleganza e via sproloquiando. I fatti, contano i fatti! Carta canta! .

A vederlo direi che funzioni. La mappa puoi dichiararla come <Integer, byte[]>, a meno che i valori non debbano effettivamente essere Object o figli. Mi sfugge la ragione per cui devi avere una mappa ma tra noi due sei senz'altro tu a sapere come dev'essere fatto 'sto programma.

[Frank1962]

Originariamente inviato da PGI-Bis

A vederlo direi che funzioni. La mappa puoi dichiararla come <Integer, byte[]>, a meno che i valori non debbano effettivamente essere Object o figli. Mi sfugge la ragione per cui devi avere una mappa ma tra noi due sei senz'altro tu a sapere come dev'essere fatto 'sto programma.

si potrei metterci anche un byte[] come tipo ....utilizzo l'hashmap per poter dar la possibilità a chi utilizza questa classe di poter associare un identificativo all'oggetto che vuole salvare nel dbmen: hai qualche alternativa? dici che con una List posso ottenere lo stesso risultato?
Sul discorso "compressione" non mi dici nulla?

[PGI-Bis]

Mi intendo di compressione come di scissione dell'atomo. So che le librerie standard fornisco compressori/decompressori zlib, zip o gzip e qui mi fermo.

[Frank1962]

Originariamente inviato da PGI-Bis

Mi intendo di compressione come di scissione dell'atomo. So che le librerie standard fornisco compressori/decompressori zlib, zip o gzip e qui mi fermo.

non sei esperto di scissione dell'atomo? ...è gravissimo per un programmatore di java avere simili lacune!!

cmq come da documentazione java della classe deflater:

setDictionary

public void setDictionary(byte[] b,int off,int len)

Sets preset dictionary for compression. A preset dictionary is used when the history buffer can be predetermined. When the data is later uncompressed with Inflater.inflate(), Inflater.getAdler() can be called in order to get the Adler-32 value of the dictionary required for decompression.

Parameters:
b - the dictionary data bytes
off - the start offset of the data
len - the length of the data
See Also:
Inflater.inflate(byte[], int, int), Inflater.getAdler()

l'idea penso sia quella di fornirgli un dizionario fissato in modo tale che lavori su quello e non vadi a crearsene ogni volta una suo andandolo a salvare insieme ai dati compressi.... ma perchè cavolaccio non mi dicono COME cavolo si crea quell'array da passare come argomento!!

[Frank1962]

cmq togliendo il problema della compressione che, da post su forum.java.sun.com (trovato dopo un casino di tempo, dato che google sembri disprezzare tale forum) il problema sembra di rapida soluzione, volevo domandarti che cosa non ti è chiaro della mia classe dopo che ho postato il codice, dalle tue parole infatti:

Mi sfugge la ragione per cui devi avere una mappa ma tra noi due sei senz'altro tu a sapere come dev'essere fatto 'sto programma.

...sembra che non riesci a trovare, se mai ci fosse, la ragione per cui un "qualcuno" dovesse implementare "sta cosa"!
Cioè, la necessità di avere un "contenitore" di oggetti limitato superiormente penso non sia cosa di poco conto come soluzione di parecchie problematiche tra i programmatori java...... o sbaglio?

[PGI-Bis]

Come no. Figurati che se non devo fare un contenitore di oggetti limitato superiormente io la mattina neanche mi alzo.

Tu devi fare quello che pensia sia corretto per il tuo programma. A me sembra strano che ti serva una mappa perchè, probabilmente, mi sono fatto un'idea del programma che è diversa da quello reale.

Il programma che mi sono immaginato è questo.

C'è un server che mastica richieste. Le richieste provengono da un numero non determinato di client.

Il server ha una limitata capacità di evasione delle richieste.

Tra il server e i client infili un buffer tampone. Il buffer accumula le richieste provenienti dai client e il server le consuma in ordine di arrivo.

Il buffer ha una dimensione prefissata. Quando il buffer si riempie, possono succedere tre cose (sempre nella mia idea del programma)

1. il buffer rifiuta le nuove richieste
2. il buffer rimpiazza la richiesta più vecchia con la richiesta più recente
3. il buffer mette i client in attesa

E qui la mappa non ci sta. La mappa permette di prelevare una richiesta in particolare. Non serve per prelevare la richiesta più vecchia o la più recente, perchè questo compito lo assolve già la coda del buffer. La mappa offre un criterio di "scelta" diverso. Qual'è questo criterio? Perchè il server dovrebbe prelevare (presumo per evadere) una richiesta senza rispettare l'ordine di arrivo? Forse alcune richieste sono prioritarie? Ma in questo caso la priorità dovrebbe essere gestita nell'accodamento delle richieste.

Ecco, sono perplessità di questo tipo che mi fanno apparire strana quella mappa. Ma questo non vuol dire che sia stramba. Insomma, se l'hai messa una ragione ci sarà. Io mi fido.