Consiglio funzioni a tempo

[Manuelandro]

Salve a tutti, è da tanto che manco in questa sezione e ammetto di essere alquanto arruginito col php.
Sono qui per chiedervi un parere, un'opinione su quale (o quali ) possa essere la soluzione per realizzare una determinata funzione.

Per ora non posto un link esempio perchè non vorrei spammare, in ogni caso se conoscete siti come bidrivals capirete cosa intendo.

Come possono essere gestite le funzioni di tempo adoperate in quei siti d'asta?

Elenco:

1)Orario prestabilito per apertura asta: e fin qui credo di esserci; o una cron tab se il server me lo permette, o apertura a mano del gestore.

2)Timer di 60 secondi dall'ultima puntata che ha due casi; a)arriva a 0 e l'asta si chiude automaticamente - b)un altro utente punta ed il timer si resetta a 60

3)Gestione delle puntate simultanee - ovvero come impedire che nello stesso momento due utenti effettuino una puntata, ma consentire la puntata a uno e rifiutarla all'altro


P.S. Vorrei evitare di utilizzare le CronTab in quanto non ho molta dimestichezza con i server, quindi gradirei realizzare tutto con php mysql e ajax per il lato client

[oronze]

ipottiziamo che nel db, oltre a tutti i dati dell'asta salvi anche la scadenza dell'asta, in pseudocodice qualcosa del genere dovrebbe essere funzionale

class Asta{

public setFine($ora){
//salva l'ora di fine asta
}
public getFine(){
//restituisce l'ora di fine asta
}
public getOra(){
//restituisce l'ora attuale
}
public faiPuntata($euro){
if(getFine() - getOra() <= 60secondi) setFine(getFine() + 60secondi);
}

}

Per quanto riguarda le puntate simultanee, questo è raramente possibile (anche se non sono espertissimo su questo argomento...magari altri ti sapranno indirizzare meglio)
Ipotizziamo in ogni caso che A e B puntino 1€ su un prodotto nello stesso preciso istante.
Il server gestirà una connessione alla volta quindi o A o B avranno puntato 1€ mentre, l'altro utente riceverà un messaggio tipo (puntata di 1€ già effettuata, devi rilanciare di minimo xx%)...credo sia qualcosa del genere.

[Grino]

Può succedere che mentre uno sta per scrivere l'altro abbia letto un dato che pochi istanti dopo viene aggiornato o aggiunto. Sui server il multi3d è una realtà e in tal caso ti puoi trovare con due soggetti che fanno la stessa puntata.
Per impedire puntate simultanee, ovvero letture e scritture sul DB fin tanto che le attività di accesso al DB di uno non sono complete puoi, se usi l'engine myisam sfruttare l'istruzione di mysql lock tables, con engine innodb avvii una transazione

[Manuelandro]

grazie ad entrambi per le risposte.
per quanto riguarda l'orario di scadenza credo di esserci, per la gestione delle query simultanee ho ancora qualche dubbio.

Ho letto in giro che c'è sia la tecnica dei LOCK che quella delle transazioni. Ora vi chiedo, delle due quale mi consigliate, tenendo conto che io ho bisogno di "bloccare" solo un determinato record e non una tabella intera?


Poi per il primo punto che avevo scritto, credo che mi affiderò ad un server con possibilità di cron; non vorrei andare in ot, ma sapreste consigliarmi un servizio di server dedicato (o virtuale se funziona uguale) che dispone già della funzione cron con magari un'interfaccia abbastanza chiara preimpostata dall'hoster?

(se non si può parlare di hosting a pagamento accetto ben volentieri anche messaggi privati)

[whisher]

Ciao,
potresti creare una tabella bids (dovrebbe gia esserci )
con pk bid_id bid e poi gestire l'errore che ti
restituisce mysql in caso di double key.

[Manuelandro]

Originariamente inviato da whisher
Ciao,
potresti creare una tabella bids (dovrebbe gia esserci )
con pk bid_id bid e poi gestire l'errore che ti
restituisce mysql in caso di double key.

non credo di riuscire a seguirti perfettamente, grazie comunque

[LeaderGL]

Originariamente inviato da Manuelandro
Poi per il primo punto che avevo scritto, credo che mi affiderò ad un server con possibilità di cron;

(1)
La crontab non ti serve a nulla. devi solo far visualizzare (ed accettare puntate) per aste la cui data di inizio è precedente alla data attuale.

(3)
Perchè dovresti avere problemi con le puntate "simultanee"? Le puntate dei singoli utenti sono indipendenti tra di loro...devi solo usare il corretto modo di gestire le offerte (e solo nel caso di alcune delle tipologie di aste)


P.S. i siti d'aste, così come tutti i siti in cui sono previsti dei pagamenti, non sono degli "scherzi" e andrebbero fatti con molta cura e sopratutto da persone "esperte" (ci possono essere notevoli risvolti legali, sopratutto con le aste a ribasso (in Italia)). Se avevi dei dubbi già sul punto 1...posso solo consiglierti di studiare prima per bene la situazione e solo dopo provare a creare il sito d'aste a ribasso.

[Manuelandro]

Originariamente inviato da LeaderGL
(1)
La crontab non ti serve a nulla. devi solo far visualizzare (ed accettare puntate) per aste la cui data di inizio è precedente alla data attuale.

hai ragione non ci avevo pensato. basterebbe inserire tutte le aste che voglio e renderle "invisibili" fino a quando non si raggiunge la data di partenza. grazie

Originariamente inviato da LeaderGL
(3)
Perchè dovresti avere problemi con le puntate "simultanee"? Le puntate dei singoli utenti sono indipendenti tra di loro...devi solo usare il corretto modo di gestire le offerte (e solo nel caso di alcune delle tipologie di aste)

guarda io ho letto in giro, anche tra le pillole qui, che anche se rari possono esserci casi di query inviate nello stesso istante. Per questo "temo" di avere problemi, in quanto vorrei che fosse il più solido possibile. Ti faccio un esempio: se nello stesso istante due utenti puntano 7,00€, ovviamente l'asta avrà un solo utente come ultimo puntatore e vincente, e dato che l'altro ha puntato la stessa cifra ed ha pagato per puntare, si ritroverà con l'aver perso i soldi della puntata inultilmente.

Originariamente inviato da LeaderGL
P.S. i siti d'aste, così come tutti i siti in cui sono previsti dei pagamenti, non sono degli "scherzi" e andrebbero fatti con molta cura e sopratutto da persone "esperte" (ci possono essere notevoli risvolti legali, sopratutto con le aste a ribasso (in Italia)). Se avevi dei dubbi già sul punto 1...posso solo consiglierti di studiare prima per bene la situazione e solo dopo provare a creare il sito d'aste a ribasso.

per le questioni legali ho già controllato tutto, ed in ogni caso non è mia intenzione realizzare un sito di aste a ribasso (come non lo è quello che ho citato inizialmente)

[LeaderGL]

Originariamente inviato da Manuelandro
guarda io ho letto in giro, anche tra le pillole qui, che anche se rari possono esserci casi di query inviate nello stesso istante. Per questo "temo" di avere problemi, in quanto vorrei che fosse il più solido possibile. Ti faccio un esempio: se nello stesso istante due utenti puntano 7,00€, ovviamente l'asta avrà un solo utente come ultimo puntatore e vincente, e dato che l'altro ha puntato la stessa cifra ed ha pagato per puntare, si ritroverà con l'aver perso i soldi della puntata inultilmente.

Il fatto è che bisogna prendere in considerazione tutti i fattori:
1) di che tipo di asta si parla
2) è realmente necessaria una gestione di questo "problema" per il tipo di asta in questione

Nei siti di aste a ribasso troviamo due tipi di aste (ce ne sono tanti, ma fondamentalmente riconducibili a due macro-categorie):
1) asta a ribasso classica: conto alla rovescia, vince l'offerta unica più bassa
2) asta a ribasso con timer incrementale: vince l'offerta unica più bassa ma ad ogni offerta il timer viene incrementato di X secondi
3) [ho detto due ma ce la aggiungerei] asta a rilancio: non è un asta a ribasso, ad ogni "rilancio" (il giocatore non sceglie l'importo) il valore dell'asta viene incrementato di X euro ed il conto alla rovescia di Y secondi

nel primo tipo di asta non ha alcuna importanza se due utenti fanno la stessa offerta, vincerà (se quella risulterà essere l'offerta fatta il minor numero di volte) il giocatore che l'ha effettuata per primo, quindi ti devi solo salvare la data dell'offerta ed avere un id incrementale per ogni offerta.

nel secondo tipo hai la stessa identica situazione del primo tipo, con l'aggiunta di dover incrementare il contatore di fine asta (qui devi gestire un po più cose ma non riguardano le offerte bensì che contatore usare per stabilire la fine dell'asta).

nel terzo tipo l'utente non fa alcuna offerta quindi non avrai due utenti che punteranno lo stesso valore, avrai solo una serie di rilanci che stabiliranno il costo finale dell'oggetto.

Come vedi in nessuna di queste aste servono particolari meccanismi per gestire la concorrenza degli utenti.

[Manuelandro]

Originariamente inviato da LeaderGL

nel terzo tipo l'utente non fa alcuna offerta quindi non avrai due utenti che punteranno lo stesso valore, avrai solo una serie di rilanci che stabiliranno il costo finale dell'oggetto.

Come vedi in nessuna di queste aste servono particolari meccanismi per gestire la concorrenza degli utenti.

innanzitutto ti ringrazio per l'ennesima risposta.
In merito a questo punto ti esprimo quello che è il mio dubbio: è vero in questo caso l'utente NON deve fare una puntata precisa ma c'è un rialzo obbligatorio, ma io temo ad esempio che:


1)Il valore attuale dell'oggetto è a 0,59€ (per assurdo)
2)due utenti fanno nello stesso istante la puntata obbligatoria di rialzo (ovvero pagano il costo della puntata ed il prezzo sale a 0,60€). Cosa succederebbe in questo caso? innanzitutto ci sarebbero due query insert nella lista delle puntate ma quelle non mi preoccupano, ma quello che mi preoccupa è che ci sarebbe una query update del valore dell'oggetto CON UN SOLO UTENTE che si è aggiudicato quella puntata. Praticamente avrei nella lista di puntate che Utente1 ha rialzato di 0,60€ alle 18:00:00 e Utente2 che ha rialzato in modo identico cioè 0,60€ alle 18:00:00. In questo caso Utente1 rimane fregato e giustamente pure!

E' questo che mi preoccupa