Importar los CDRs a la tabla cdr de una bd MySQL
Javier Hernández
Asterisk 1.8.3.2
Ubuntu 10.10 Maverick 64 bits
MySQL Server 5.1.49-1ubuntu8.1
####################################################
*CLI> cdr show status
Call Detail Record (CDR) settings
----------------------------------
Logging: Enabled
Mode: Simple
Log unanswered calls: No
* Registered Backends
-------------------
csv
cdr-custom
###################################################
Si ejecuto >> cat /var/log/asterisk/cdr-csv/Master.csv
Muestra todos los CDRs que hay.
El problema que tengo es que no me los importa a la tabla cdr de la
base de datos.
En cdr_mysql.conf tengo la ip del servidor mysql y las credenciales,
lo que tengo una duda con sock=/tmp/mysql.sock
¿es correcto así?
En cdr.conf en [general] tengo enable=yes y unanswered = no , que es
lo que aparece arriba al ejecutar en el CLI cdr show status.
y más abajo:
[csv]
usegmtime=yes ; log date/time in GMT. Default is "no"
loguniqueid=yes ; log uniqueid. Default is "no"
loguserfield=yes ; log user field. Default is "no"
accountlogs=yes ; create separate log file for each account code.
Default is "yes"
todo lo demás está comentado.
¿Qué me falta para que Asterisk inserte los CDRs en la tabla?
Saludos
Javier Hernández
[general]
dbhost = 127.0.0.1
dbname = basedatoscdrs
dbuser = user
dbpass = 12345
dbport = 3306
dbsock = /tmp/mysql.sock
dbcharset = latin1
Iñaki Baz Castillo
<javas...@gmail.com> escribió:
> * Registered Backends
> -------------------
> csv
> cdr-custom
No tienes cargado el módulo cdr-mysql o cdr-odbc. Difícil entonces.
--
Iñaki Baz Castillo
<i...@aliax.net>
Richard Alvarez
--
Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)
~~~ Normas de la lista Asterisk-ES: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://comunidad.asterisk-es.org/index.php?title=Lista:normas-asterisk-es
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Para anular la suscripción: asterisk-es...@googlegroups.com
Saúl Ibarra Corretgé
module load cdr_mysql.so
Y comprueba que esté cargado después:
module show like cdr_
--
/Saúl
http://saghul.net | http://sipdoc.net
Javier Hernández
es eso, que no lo tengo cargado, es lo que me falta, que no es poco.
########################## module show like mysql
######################################
Module
Description Use Count
0 modules loaded
################################ module show like cdr_
####################################
Module
Description Use Count
cdr_manager.so Asterisk Manager Interface CDR
Backend 0
cdr_csv.so Comma Separated Values CDR
Backend 0
cdr_syslog.so Customizable syslog CDR
Backend 0
cdr_custom.so Customizable Comma Separated Values
CDR 0
4 modules loaded
################ En el S.O. /usr/lib/asterisk/modules# ls cdr_*
###########################
cdr_csv.so cdr_custom.so cdr_manager.so cdr_syslog.so
############################################################################################
No está el modulo cdr_mysql.so aquí (si es que se llama así)
¿Hay qué descargarlo o recompilar Asterisk (make menuselect) ?
Saludos
Javier Hernández
Unable to load module cdr_mysql
Command 'module load cdr_mysql' failed.
*CLI> [Mar 23 16:41:34] WARNING[6671]: loader.c:387
load_dynamic_module: Error loading module 'cdr_mysql': /usr/lib/
asterisk/modules/cdr_mysql.so: cannot open shared object file: No such
file or directory
[Mar 23 16:41:34] WARNING[6671]: loader.c:839 load_resource: Module
'cdr_mysql' could not be loaded.
######################################
Iñaki Baz Castillo
<javas...@gmail.com> escribió:
> No está el modulo cdr_mysql.so aquí (si es que se llama así)
>
> ¿Hay qué descargarlo o recompilar Asterisk (make menuselect) ?
lmgtfy.com/?q=asterisk cdr_mysql
Javier Hernández
Lo que pregunto es de donde puedo descargar el modulo cdr_mysql.so
para Asterisk 1.8. Todo lo demás ya lo tengo configurado. Y en google
solo encuentro info para la 1.6
On 23 mar, 16:52, Iñaki Baz Castillo <i...@aliax.net> wrote:
> El día 23 de marzo de 2011 17:39, Javier Hernández
Javier Hernández
Me has dado una idea, y así simplifico las cosas.
Creo que lo voy a hacer así, no tengo por qué utilizar MySQL, así me
quito una unidad de persistencia de encima y tener que utilizar el
lenguaje SQL, además de mantener otro servidor de base de datos.
Java maneja bien los .csv por lo que jalo desde ahí todos los cdrs y
luego ya en Java los muestro en un jTable y los guardo en la BD Oracle
11g que tengo, adicional a la de MySQL, y ahí en Oracle 11g le añado
los demás campos que necesito.
Gracias de nuevo a todos, y en especial a tí Iñaki por molestarte en
buscarme las cosas en Google :)
Bendiciones!
On 23 mar, 16:07, Richard Alvarez <rich...@gmail.com> wrote:
> Quieres importar los registros guardados en el archivo Master.csv a la tabla
> cdr en mysql ?
> O quieres que te grabe asterisk los registros de llamadas directamente en
> esa tabla?
>
> *
> Email.: rich...@gmail.com
> El 23 de marzo de 2011 12:42, Javier Hernández <javaster...@gmail.com>escribió:
>
>
>
>
>
>
>
> > En res_config_mysql.conf está lo siguiente:
>
> > [general]
> > dbhost = 127.0.0.1
> > dbname = basedatoscdrs
> > dbuser = user
> > dbpass = 12345
> > dbport = 3306
> > dbsock = /tmp/mysql.sock
> > dbcharset = latin1
>
> > --
> > Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org
> > )
>
> > ~~~ Normas de la lista Asterisk-ES: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Iñaki Baz Castillo
<javas...@gmail.com> escribió:
> Java maneja bien los .csv por lo que jalo desde ahí todos los cdrs y
> luego ya en Java los muestro en un jTable y los guardo en la BD Oracle
> 11g que tengo, adicional a la de MySQL, y ahí en Oracle 11g le añado
> los demás campos que necesito.
Pero ojo, una cosa es manejar un CSV con 1000 líneas y otras manejar
un CSV con 1000000 líneas. Tendrás que rotar los ficheros Master.csv,
decir a tu aplicación que busque en el fichero adecuado según la fecha
que buscas de CDR's, etc.
Por otra parte esto también aplica a la tabla CDR cuando se usa base
de datos. Si hay muchas llamadas diarias conviene rotar esa tabla caad
X tiempo, etc, y esto añade complejidad a las aplicaciones web (que no
sólo tienen que leer de una única tabla sino de varias en función de
la fecha a consultar, etc).
Javier Hernández
On 23 mar, 17:43, Iñaki Baz Castillo <i...@aliax.net> wrote:
> El día 23 de marzo de 2011 18:37, Javier Hernández
> > Java maneja bien los .csv por lo que jalo desde ahí todos los cdrs y
> > luego ya en Java los muestro en un jTable y los guardo en la BD Oracle
> > 11g que tengo, adicional a la de MySQL, y ahí en Oracle 11g le añado
> > los demás campos que necesito.
>
> Pero ojo, una cosa es manejar un CSV con 1000 líneas y otras manejar
> un CSV con 1000000 líneas. Tendrás que rotar los ficheros Master.csv,
> decir a tu aplicación que busque en el fichero adecuado según la fecha
> que buscas de CDR's, etc.
los nombre por días, es decir para los cdrs de hoy que cree un archivo
23032011.csv ¿es posible?, como se puede hacer con la aplicación
Monitor que le puedes dar las ubicaciones de donde quieres guardar las
grabaciones y como nombrarlas.
>
> Por otra parte esto también aplica a la tabla CDR cuando se usa base
> de datos. Si hay muchas llamadas diarias conviene rotar esa tabla caad
> X tiempo, etc, y esto añade complejidad a las aplicaciones web (que no
> sólo tienen que leer de una única tabla sino de varias en función de
> la fecha a consultar, etc).
>
by RedHat
Para las consultas por fechas, extensiones y todo eso yo utilizo
Criteria, que es lo mejor para las consultas, sobre todo si son
complejas.
Richard Alvarez
--
Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)
~~~ Normas de la lista Asterisk-ES: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jon Bonilla
Iñaki Baz Castillo <i...@aliax.net> escribió:
> Por otra parte esto también aplica a la tabla CDR cuando se usa base
> de datos. Si hay muchas llamadas diarias conviene rotar esa tabla caad
> X tiempo, etc, y esto añade complejidad a las aplicaciones web (que no
> sólo tienen que leer de una única tabla sino de varias en función de
> la fecha a consultar, etc).
>
Puedes usar engines diferentes para eso. Por ejemplo merge. Haces 60 tablas
unidas y las rotas. Haces la búsqueda en la unida.
O contratas a gente que sepa hacer las consultas sin poner LIKE en todo y sepan
dónde poner los índices.
Es muy raro tener que rotar tablas. Lo que has son muchos "php masters"
Saúl Ibarra Corretgé
> jaja gracias estaba buscando esa web.
>
> Lo que pregunto es de donde puedo descargar el modulo cdr_mysql.so
> para Asterisk 1.8. Todo lo demás ya lo tengo configurado. Y en google
> solo encuentro info para la 1.6
>
En la 1.8 está incluido dentro del apartado 'addons', y por defecto
viene deshabilitado.
Javier Hernández
Lo que hago, de momento , es vaciar el csv todas las noches a las 24
horas.
On 23 mar, 17:47, Richard Alvarez <rich...@gmail.com> wrote:
> El 23 de marzo de 2011 14:43, Iñaki Baz Castillo <i...@aliax.net> escribió:
>
>
>
>
>
>
>
>
>
> > El día 23 de marzo de 2011 18:37, Javier Hernández
> > > luego ya en Java los muestro en un jTable y los guardo en la BD Oracle
> > > 11g que tengo, adicional a la de MySQL, y ahí en Oracle 11g le añado
> > > los demás campos que necesito.
>
> > Pero ojo, una cosa es manejar un CSV con 1000 líneas y otras manejar
> > un CSV con 1000000 líneas. Tendrás que rotar los ficheros Master.csv,
> > decir a tu aplicación que busque en el fichero adecuado según la fecha
> > que buscas de CDR's, etc.
>
> > Por otra parte esto también aplica a la tabla CDR cuando se usa base
> > de datos. Si hay muchas llamadas diarias conviene rotar esa tabla caad
> > X tiempo, etc, y esto añade complejidad a las aplicaciones web (que no
> > sólo tienen que leer de una única tabla sino de varias en función de
> > la fecha a consultar, etc).
>
> Cada cuantos registros en la tabla cdr estimas que hay que pasar estos a una
> tabla histórica?
>
>
>
>
>
>
>
>
>
> > --
> > Iñaki Baz Castillo
> > <i...@aliax.net>
>
> > --
> > Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org
> > )
>
> > ~~~ Normas de la lista Asterisk-ES: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Javier Hernández
maneras no lo voy a utilizar.
Lo que hago es crear un objeto (Java) con los datos de Master.csv y
esos datos luego con el ORM los puedo guardar en cualquier base de
datos, MySQL, Oracle, Porstgre, Sqlite o a la que sea, en este caso
Oracle 11g, junto con los datos que recoge mi aplicación, Comentarios
de la llamada, Dirección, etc.etc..
Saludos
On 23 mar, 19:28, Saúl Ibarra Corretgé <sag...@gmail.com> wrote:
> 2011/3/23 Javier Hernández <javaster...@gmail.com>:
Javier Hernández
de Master.csv, se puede hacer antes de vaciarlo, nombrándolo por
ejemplo Master-23032011.csv.bak (por ejemplo).
Habrán más formas de hacerlo y más elegantes, pero esta funciona
Ramses
Saludos,
Ramses
Enviado desde mi Móvil
> http://comunidad.asterisk-es.org/index.php?title=Lista:normas-asterisk-es
Javier Hernández
On 23 mar, 20:47, Ramses <ramses.sevi...@gmail.com> wrote:
> Ya que nadie lo dice, lo digo yo: ¿Has pensado en logrotate?
>
> Saludos,
>
> Ramses
>
> Enviado desde mi Móvil
>
Javier Hernández
archivos log con lo que quiera, La aplicación monitorea todo, casi
como lo hace Asterisk, lo que vemos en el Cli, canales que se
puentean, extensiones que se registran, desregistran, canales que
coloca en answer o hangup, canales que coloca en musichold, etc...
etc....
Y con Log4j ya te digo podría crear un archivo log para cada cosa,
comprimirlo, encriptarlo, y cualquier otra cosa que pueda necesitar,
bueno no con Log4j todo, jeje con Java :)
>
> Saludos,
>
> Ramses
>
> Enviado desde mi Móvil
>
Javier Hernández
> El Wed, 23 Mar 2011 18:43:08 +0100
> Iñaki Baz Castillo <i...@aliax.net> escribió:
>
> > Por otra parte esto también aplica a la tabla CDR cuando se usa base
> > de datos. Si hay muchas llamadas diarias conviene rotar esa tabla caad
> > X tiempo, etc, y esto añade complejidad a las aplicaciones web (que no
> > sólo tienen que leer de una única tabla sino de varias en función de
> > la fecha a consultar, etc).
"concurrentemente" de la misma tabla. :)
(pero para eso está la Concurrencia en Java, imagino que en otros
lenguajes también, pero yo solo uso Java).
Para eso uso el Semáforo >> http://download.oracle.com/javase/6/docs/api/java/util/concurrent/Semaphore.html
Javier Hernández
@Richard, quedó de perlas jalando los datos desde el csv, mira como se
ve en el debugueador >> http://bit.ly/ggjqrV
Bendiciones!!
Saúl Ibarra Corretgé
> Ya gracias Saúl, por cuestiones de licencia me imagino, de todas
> maneras no lo voy a utilizar.
>
> Lo que hago es crear un objeto (Java) con los datos de Master.csv y
> esos datos luego con el ORM los puedo guardar en cualquier base de
> datos, MySQL, Oracle, Porstgre, Sqlite o a la que sea, en este caso
> Oracle 11g, junto con los datos que recoge mi aplicación, Comentarios
> de la llamada, Dirección, etc.etc..
>
Puedes usar cdr_adaptive_odbc y conectar directamente Asterisk con
Oracle mediante ODBC, y al ser adaptivo puedes añadir todos los campos
que quieras.
Iñaki Baz Castillo
> Cada cuantos registros en la tabla cdr estimas que hay que pasar estos a una
> tabla histórica?
Depende de si esa misma tabla se usa para lectura. Concretamente con
MySQL y tablas MyISAM (por defecto en MySQL) si una query hace un JOIN
entonces dicha tabla se bloquea completamente y no se puede escribir
en ella hasta que termine la query del JOIN (creo que con InnoDB no
ocurre eso). Esto significa que si tienes una aplicación de consulta
de CDR (web por ejemplo) que mira esa misma tabla (y no una replicada)
y hace consultas muy bestias sobre muchos registros y encima hace un
JOIN con otra tabla, pues Asterisk puede empezar a sufrir si no la
query INSERT de una nueva llamada no funciona.
De hecho, por mi experiencia puedo afirmar que tanto cdr-mysql como
cdr-odbc se vuelven locos cuando el server MySQL falla (no responde
debido a sobrecarga) o tiene el máximo número de conexiones usadas,
etc. En ese callo los INSERT de nuevos cdrs fallan y Asterisk empieza
misteriosamente a consumir mucha CPU y memoria, hasta que llega un
punto en el que comienza a no hablar SIP (no responde a los requests
SIP) y finalmente revienta y cae (el tiempo de esta caída es
inversamente proporcional al número de cdr's que no se han podido
escribir).
En cambio, si suponemos un escenario en el que asterisk escribe cdr en
MySQL-1 y existe replicación master-slave de la tabla cdr a MySQL-2, y
la aplicación de consulta sólo lee de MySQL-2, entonces no habría
problema por mucho que crezca la tabla cdr en MySQL-1 puesto que a las
operaciones de escritura como INSERT les da igual el número de
registros que haya en la tabla (OJO, esto es totalmente falso si la
tabla tiene muchos índices, puesto que por cada edición en la tabla se
deben recalcular, y cuantos más registros haya más lento es).
Si se tiene un poco de cuidado con esto que digo, yo creo que se puede
operar con una tabla cdrs con unos pocos millones sin problema. Esta
cifra disminuye drásticamente si se usa la misma tabla para escritura
de CDRs y lectura desde una aplicación de consulta.
Saludos.
Iñaki Baz Castillo
<javas...@gmail.com> escribió:
> jeje, y más cuando múltiples usuarios tienen que leer/escribir
> "concurrentemente" de la misma tabla. :)
>
> (pero para eso está la Concurrencia en Java, imagino que en otros
> lenguajes también, pero yo solo uso Java).
No entiendo. Un servidor de base de datos ya implementa todos los
temas de concurrencia, etc por sí mismo, de hecho es obvio que varios
clientes pueden hacer consultas de lectura/escritura a la vez y el
server DB ya se encarga de hacer locks cuando sea necesario (cosa que
depende del server en sí, del tipo de tabla, etc).
Entonces, salvo que te refieras a que a nivel de aplicación (Java)
impidas que un usuario consulte sus CDR's si hay otro usuario en ese
momento también consultando sus CDR's... pues no sé a qué te refieres,
y obviamente hacer esto último sería bastante cutre y poco
user-friendly. Seguramente no he entendido bien a qué te refieres.
Iñaki Baz Castillo
> En cambio, si suponemos un escenario en el que asterisk escribe cdr en
> MySQL-1 y existe replicación master-slave de la tabla cdr a MySQL-2, y
> la aplicación de consulta sólo lee de MySQL-2, entonces no habría
> problema por mucho que crezca la tabla cdr en MySQL-1 puesto que a las
> operaciones de escritura como INSERT les da igual el número de
> registros que haya en la tabla (OJO, esto es totalmente falso si la
> tabla tiene muchos índices, puesto que por cada edición en la tabla se
> deben recalcular, y cuantos más registros haya más lento es).
Para esto último, una solución podría ser no tener ningún índice en la
tabla cdr de MySQL-1 (el master donde asterisk escribe y NADIE lee), y
crear los índices necesarios sólo en la tabla cdr replicada en MySQL-2
(el slave donde sólo se hacen consultas de lectura y donde, por ende,
tiene sentido disponer de índices).
Javier Hernández
tabla en Oracle y ya hice el mapeo objeto relacional ahora ya solo me
queda pasarle los valores de las variables del objeto que lee a
Master.csv al constructor y listo Hibernate hace todo el trabajo de
enviar esos datos a Oracle.
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD
3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<!-- Generated 23-mar-2011 23:15:04 by Hibernate Tools 3.2.1.GA -->
<hibernate-mapping>
<class name="es.cdr.oracle.DetalleLlamadas"
table="DETALLE_LLAMADAS" schema="SCHEMA">
<id name="incidenciaid" type="big_decimal">
<column name="TICKETID" precision="22" scale="0" />
<generator class="increment" />
</id>
<property name="accountcode" type="string">
<column name="ACCOUNTCODE" length="20" not-null="true" />
</property>
<property name="origen" type="string">
<column name="ORIGEN" length="80" not-null="true" />
</property>
<property name="destino" type="string">
<column name="DESTINO" length="80" not-null="true" />
</property>
<property name="contextoDestino" type="string">
<column name="CONTEXTO_DESTINO" length="80" not-
null="true" />
</property>
<property name="clid" type="string">
<column name="CLID" length="80" not-null="true" />
</property>
<property name="canal" type="string">
<column name="CANAL" length="80" not-null="true" />
y este es el constructor
public DetalleLlamadas(BigDecimal incidenciaid, String accountcode,
String origen, String destino, String contextoDestino, String clid,
String canal, String lastapp, BigDecimal inicio, BigDecimal
contestado, BigDecimal fin, BigDecimal duracion, BigDecimal billsec,
String disposicion, BigDecimal amaflags, String canalDestino) {
On 23 mar, 21:43, Saúl Ibarra Corretgé <sag...@gmail.com> wrote:
> 2011/3/23 Javier Hernández <javaster...@gmail.com>:
>
Javier Hernández
> No entiendo. Un servidor de base de datos ya implementa todos los
> temas de concurrencia, etc por sí mismo, de hecho es obvio que varios
> clientes pueden hacer consultas de lectura/escritura a la vez y el
> server DB ya se encarga de hacer locks cuando sea necesario (cosa que
> depende del server en sí, del tipo de tabla, etc).
>
> Entonces, salvo que te refieras a que a nivel de aplicación (Java)
> impidas que un usuario consulte sus CDR's si hay otro usuario en ese
> momento también consultando sus CDR's... pues no sé a qué te refieres,
> y obviamente hacer esto último sería bastante cutre y poco
> user-friendly. Seguramente no he entendido bien a qué te refieres.
>
es un problema de Java solo, es un problema típico de programación que
se suele dar con cualquier lenguaje. Los semáforos se utilizan para
restringir el número de Threads que pueden acceder al mismo recurso
(físicos o lógicos).
Lo analizaron y resolvieron por primera vez Pierre Jacques Courtois,
F. Heymans y David Lorge Parnas en un artículo de investigación
llamado "Concurrent Control with Readers and Writers" en ACM (http://
cacm.acm.org/) en octubre de 1971. http://cs.nyu.edu/~lerner/spring11/MCP-S11-Read04-ReadersWriters.pdf
o aquí http://comjnl.oxfordjournals.org/content/25/1/121.full.pdf
Iñaki Baz Castillo
<javas...@gmail.com> escribió:
> Se utiliza para cubrir secciones críticas. Y no, estoy viendo que no
> es un problema de Java solo, es un problema típico de programación que
> se suele dar con cualquier lenguaje. Los semáforos se utilizan para
> restringir el número de Threads que pueden acceder al mismo recurso
> (físicos o lógicos).
Javier, sé lo que es un semáforo. A lo que me refería es a que tú
planteabas un supuesto problema en caso de que muchos usuarios
escriban/lean a la vez de una base de datos, y luego hablabas de
semáforos a nivel de Java para solucionarlo. ¿Solucionar el qué? No sé
si me explico.
Javier Hernández
Yo no he planteando ningún supuesto caso, lo has planteado tú y con
una supuesta aplicación Web, que no es mi caso.
Yo lo que he escrito ha sido: "y más cuando múltiples usuarios tienen
"concurrentemente" de la misma tabla. "
Javier Hernández
directamente del csv los importo a Java y ya luego con Pojos y
ficheros de mapeo añado los campos que quiera, tengo unas clases que
renderizan las fechas (que suelen estar al revés) y cosas como
disposition para que las guarde en castellano y luego lo envío todo a
Oracle 11g.
Para las consultas (lecturas) complejas utilizo la API Criteria de
RedHat http://docs.jboss.org/hibernate/core/3.5/reference/en/html/querycriteria.html
Y para lo demás utilizo el lenguaje de Hibernate HQL
http://docs.jboss.org/hibernate/core/3.3/reference/en/html/queryhql.html
Podría también utilizar SQL navito pero nunca lo utilizo.
http://docs.jboss.org/hibernate/core/3.3/reference/en/html/querysql.html
On 23 mar, 23:07, Iñaki Baz Castillo <i...@aliax.net> wrote:
Javier Hernández
bueno, solo 12 plazos de 1.930$ http://bit.ly/cwevfb
Lo de jalar los cdrs desde el log no me convence mucho, se añaden a
Oracle perfectamente, pero el problema lo tengo al volver a leer al
archivo no tengo un id único, y tendría que hacer ñapas como vaciarlo
o borrarlo y crear otro csv y si en ese momento se genera un cdr lo
perdería.
Lo voy a hacer con AMI, que ya lo utilizo y asterisk-java, tengo
cargado el módulo cdr_manager que dispara un evento cada vez que se
genera un cdr (cuando finaliza una llamada) y lo que hago es que
cuando el evento llegue a la aplicación cogo los datos que necesito y
los meto en Oracle http://asterisk-java.org/development/apidocs/org/asteriskjava/manager/event/CdrEvent.html
Con esto creo que ya asunto cerrado (espero).
ra...@dimension-virtual.com
> Se utiliza para cubrir secciones críticas. Y no, estoy viendo que no
> es un problema de Java solo, es un problema típico de programación que
> se suele dar con cualquier lenguaje. Los semáforos se utilizan para
> restringir el número de Threads que pueden acceder al mismo recurso
> (físicos o lógicos).
Los semáforos, es un recurso que hay que evitar todo lo posible, si tu
aplicación está llena de ellos, mal royo, a no ser que estés todo el
día pelando con recursos bloqueantes, claro.
En el desarrollo de aplicaciones para asterisk, etc. al nivel del que
hablamos (proceso de CDR's), no veo la necesidad de su uso, en absoluto.
Saludos
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
ra...@dimension-virtual.com
> Lo voy a hacer con AMI, que ya lo utilizo y asterisk-java, tengo
> cargado el módulo cdr_manager que dispara un evento cada vez que se
> genera un cdr (cuando finaliza una llamada) y lo que hago es que
> cuando el evento llegue a la aplicación cogo los datos que necesito y
> los meto en Oracle
> http://asterisk-java.org/development/apidocs/org/asteriskjava/manager/event/CdrEvent.html
>
> Con esto creo que ya asunto cerrado (espero).
Es otra forma de hacerlo, aunque sigo pensando que te estas
complicando la vida innecesariamente.
Iñaki Baz Castillo
<javas...@gmail.com> escribió:
Vale, voy a hacer un copy&paste de tu texto original:
-------------------------------------------------------------------------------------------------
jeje, y más cuando múltiples usuarios tienen que leer/escribir
"concurrentemente" de la misma tabla. :)
(pero para eso está la Concurrencia en Java, imagino que en otros
lenguajes también, pero yo solo uso Java).
Para eso uso el Semáforo
--------------------------------------------------------------------------------------------------
O sea:
1) Planteas el problema del acceso concurrente a BD (que no es un
problema en sí mismo, salvo que me hables de que se satura el server
DB).
2) Para ese "supuesto" problema del punto 1 sugieres "la Concurrencia en Java".
3) Y más específicamente sugieres el uso de "Semáforo".
O yo estoy muy espeso o efectivamente tú hablas de "solucionar" el
supuesto problema de acceso concurrente a BD mediante el uso de
semáforos en Java.
Tal vez te refieras a que a nivel de aplicación (Java) no ejecutas una
nueva query SQL si en ese momento hay más de N queries activas en
proceso, lo cuál según el caso podría ayudar a no saturar la BD. Pero
vamos, estoy especulando.
Saludos.
Javier Hernández
Al final esto funcionó, cada vez que se genera un CDR llega un evento
a la aplicación y entonces hago que guarde los datos en la BD.
Lo de los semáforos, no le des vueltas, era solo que le decía a Iñaki
que aún se complica más la cosa cuando varios usuarios quieren acceder
al mismo tiempo al mismo recurso. (fue un pequeño comentario en su OFF-
TOPIC :), porque la verdad no se a que vino lo que planteó :), pero en
fin.
Saludos
On 24 mar, 10:46, r...@dimension-virtual.com wrote:
> Javier Hernández <javaster...@gmail.com> escribió:
> > Lo voy a hacer con AMI, que ya lo utilizo y asterisk-java, tengo
> > cargado el módulo cdr_manager que dispara un evento cada vez que se
> > genera un cdr (cuando finaliza una llamada) y lo que hago es que
> > cuando el evento llegue a la aplicación cogo los datos que necesito y
> > los meto en Oracle
Iñaki Baz Castillo
<javas...@gmail.com> escribió:
> Lo de los semáforos, no le des vueltas, era solo que le decía a Iñaki
> que aún se complica más la cosa cuando varios usuarios quieren acceder
> al mismo tiempo al mismo recurso. (fue un pequeño comentario en su OFF-
> TOPIC :), porque la verdad no se a que vino lo que planteó :), pero en
> fin.
Javier, el que ha sacado el tema de los semáforos has sido tú, y
simplemente he preguntado su relación con las consultas a BD (ya que
como he puesto en otro correo, tú habías sugerido usar semáforos para
evitar no sé qué problema cuando varios usuarios acceden a la DB de
forma concurrente).
Pero bueno, creo que nos vamos por las ramas, igual es hora de acabar
este offñtopic :)
Javier Hernández
Manwe.
Te copio el comentario tuyo y de Manwe:
El Wed, 23 Mar 2011 18:43:08 +0100
Iñaki Baz Castillo <i...@aliax.net> escribió:
>> Por otra parte esto también aplica a la tabla CDR cuando se usa base
>> de datos. Si hay muchas llamadas diarias conviene rotar esa tabla caad
>> X tiempo, etc, y esto añade complejidad a las aplicaciones web (que no
>> sólo tienen que leer de una única tabla sino de varias en función de
>> la fecha a consultar, etc).
>unidas y las rotas. Haces la búsqueda en la unida.
>O contratas a gente que sepa hacer las consultas sin poner LIKE en todo y sepan
>dónde poner los índices.
>Es muy raro tener que rotar tablas. Lo que has son muchos "php masters"
añade la concurrencia u otras cosas como la Integridad, Autenticación,
No repudiación, etcc en la seguridad de la aplicación, solo era eso,
no que Yo tenga el problema de concurrencia, para nada, ni siquiera
tengo el (hipotético) problema que planteas de tener 1.000.000 de
llamadas diarias. (ojalá :)
Aún así si tuviera un millón de registros en una tabla, creo que no
ocurría nada, porque el servidor que tiene instalado Oracle, es un
mega servidor Dell (independiente al de Asterisk), que seguro que ese
millón de registros los leía en segundos.
Ya que salió el tema te digo lo que hago/necesito, si a los 30 días no
se solicitado ningún CDR o ninguna grabación, lo que hago es las
grabaciones las comprimo y las muevo a otro servidor, eso ya lo tengo
programado en el contrab del servidor Asterisk, y los CDR voy creando
tablas históricas por cada mes. (CDR_032011).
>>O yo estoy muy espeso o efectivamente tú hablas de "solucionar" el
>>supuesto problema de acceso concurrente a BD mediante el uso de
>>semáforos en Java.
BD o cualquier otro recurso), entre otras cosas Semaphore, estos son
los 3 paquetes que hay para eso:
http://download.oracle.com/javase/6/docs/api/java/util/concurrent/package-summary.html
http://download.oracle.com/javase/6/docs/api/java/util/concurrent/locks/package-summary.html
http://download.oracle.com/javase/6/docs/api/java/util/concurrent/atomic/package-summary.html
>>Tal vez te refieras a que a nivel de aplicación (Java) no ejecutas una
>>nueva query SQL si en ese momento hay más de N queries activas en
>>proceso, lo cuál según el caso podría ayudar a no saturar la BD. Pero
>>vamos, estoy especulando.
yo no uso SQL, para nada (no se por qué se les ha metido en la cabeza
eso de SQL), uso HQL.
Y para consultas complejas, donde hay que filtrar muchos campos, la
API Criteria (de Hibernate, jBoss (de Red-Hat))
http://www.javalobby.org/articles/hibernatequery102/
La ventaja de usar HQL, API Criteria, que no tienes que conocer el
lenguaje de la BD con la que vaya a trabajar tú aplicación, tu lo
programas y el mismo código vale para cualquier BD del mercado.
Desventaja, que tienes que aprender dos nuevos lenguajes.
En realidad, cuando haces una query Criteria, lo que haces es generar
una consulta HQL de manera totalmente transparente al programador. Es
lo más recomendado para hacer consultas grandes como las de las webs
de viajes que necesitan filtrar por muchos campos.
Bueno en fin a mi aplicación en Java no le ocurre absolutamente nada,
todo lo contrario funciona perfectamente, también tiene incluido un UA
SIP para realizar/recibir llamadas, las coloca en espera y las devía
seleccionando un destinatario desde una lista desplegable (jComoBox).
Pero bueno esto son cosas de otros foros/listas, no tiene nada que ver
con Asterisk, ya no estamos saliendo del tema de la lista (hace rato
me da). :)
Saludos
Javier Hernández
que solo me pasaba a mí)
>> tú habías sugerido usar semáforos para
>> evitar no sé qué problema cuando varios usuarios acceden a la DB de
>> forma concurrente).
On 24 mar, 15:00, Iñaki Baz Castillo <i...@aliax.net> wrote:
> El día 24 de marzo de 2011 15:27, Javier Hernández
> > Lo de los semáforos, no le des vueltas, era solo que le decía a Iñaki
> > que aún se complica más la cosa cuando varios usuarios quieren acceder
> > al mismo tiempo al mismo recurso. (fue un pequeño comentario en su OFF-
> > TOPIC :), porque la verdad no se a que vino lo que planteó :), pero en
> > fin.
>
> Javier, el que ha sacado el tema de los semáforos has sido tú, y
> simplemente he preguntado su relación con las consultas a BD (ya que
> como he puesto en otro correo, tú habías sugerido usar semáforos para
> evitar no sé qué problema cuando varios usuarios acceden a la DB de
> forma concurrente).
>
> Pero bueno, creo que nos vamos por las ramas, igual es hora de acabar
> este offñtopic :)
ra...@dimension-virtual.com
> Iñaki, era un comentario off-topic, al igual que el tuyo y el de
> Manwe.
Xiacoñoooooooo ... a ver si cerramos ya el hilo este ...
> Aún así si tuviera un millón de registros en una tabla, creo que no
> ocurría nada, porque el servidor que tiene instalado Oracle, es un
> mega servidor Dell (independiente al de Asterisk), que seguro que ese
> millón de registros los leía en segundos.
Fíate de eso y no comas, he visto ultra-servidores-de-la-muerte hincar
la rodilla en el suelo porque la base de datos estaba mal diseñada, y
no necesitabas hacer una consulta en una tabla de 1M de registros para
eso. Solo necesitas una BD mal diseñada y consultas peor echas.
> Ya que salió el tema te digo lo que hago/necesito, si a los 30 días no
> se solicitado ningún CDR o ninguna grabación, lo que hago es las
> grabaciones las comprimo y las muevo a otro servidor, eso ya lo tengo
> programado en el contrab del servidor Asterisk, y los CDR voy creando
> tablas históricas por cada mes. (CDR_032011).
Es una buena opción.
> Y así es, para solucionar la concurrencia en Java se utiliza (para una
> BD o cualquier otro recurso), entre otras cosas Semaphore, estos son
> los 3 paquetes que hay para eso:
Si estás insinuando, que TÚ a nivel aplicación, controlas la
concurrencia de consultas a la base de datos o las operaciones contra
la misma ... voy a empezar a pensar seriamente, que tienes problemas
de base en programación.
Es la capa de acceso a la base de datos (ODBC, libmysqlclient, libpq,
etc.), la que tiene que realizar ese trabajo, no tú a nivel
aplicación. Solo se me ocurre un caso en el que tengas que hacerlo tú
y no la librería de conexión al RDBMS, y es el caso de programación
asíncrona y que quieras trabajar con patrones de pools de conexiones
al motor de la RDBMS, multihilos y cosas por el estilo. Pero para eso
tendríamos que estar hablando de muchar carga, para que justificara el
esfuerzo.
> Sí creo que estás especulando, si has leído mis hilos, te fijarás que
> yo no uso SQL, para nada (no se por qué se les ha metido en la cabeza
> eso de SQL), uso HQL.
Que para el caso viene siendo casi lo mismo.
> Y para consultas complejas, donde hay que filtrar muchos campos, la
> API Criteria (de Hibernate, jBoss (de Red-Hat))
> http://www.javalobby.org/articles/hibernatequery102/
>
> La ventaja de usar HQL, API Criteria, que no tienes que conocer el
> lenguaje de la BD con la que vaya a trabajar tú aplicación, tu lo
> programas y el mismo código vale para cualquier BD del mercado.
Sí, siempre me ha hecho gracia eso de las capas, sobre capas ... si al
final, en el 95% de los casos, ya sabes de ante mano que motor de
RDBMS vas a usar y que no se va a cambiar durante la vida de la
aplicación.
> Desventaja, que tienes que aprender dos nuevos lenguajes.
>
> En realidad, cuando haces una query Criteria, lo que haces es generar
> una consulta HQL de manera totalmente transparente al programador. Es
> lo más recomendado para hacer consultas grandes como las de las webs
> de viajes que necesitan filtrar por muchos campos.
Que es un ORM vamos ...
> Bueno en fin a mi aplicación en Java no le ocurre absolutamente nada,
> todo lo contrario funciona perfectamente, también tiene incluido un UA
> SIP para realizar/recibir llamadas, las coloca en espera y las devía
> seleccionando un destinatario desde una lista desplegable (jComoBox).
> Pero bueno esto son cosas de otros foros/listas, no tiene nada que ver
> con Asterisk, ya no estamos saliendo del tema de la lista (hace rato
> me da). :)
Sí ... a ver si lo dejamos aquí ya, por favor.
Richard Alvarez
Quiero agregar mi opinión a este hilo que se estiro ya mucho:
Realmente, pensaba que las base de datos relacionales manejaban mejor la concurrencia.
Javier Hernández
>>Es otra forma de hacerlo, aunque sigo pensando que te estas
>>complicando la vida innecesariamente.
On 24 mar, 16:49, r...@dimension-virtual.com wrote:
> Javier Hernández <javaster...@gmail.com> escribió:
Javier Hernández
año, las cuales está procesando ahora.
Y con 2Gb de Ram? Este creo que vaya bien entonces, porque tiene 4Gb
de Ram y es un Quad Core, por lo que por esa regla de 3 podría manejar
3.650.000 CDRs al año sin problemas. (que no es mi caso porque ya
desinstalé mysql-sever :)
Saludos
Iñaki Baz Castillo
<javas...@gmail.com> escribió:
>>> tú habías sugerido usar semáforos para
>>> evitar no sé qué problema cuando varios usuarios acceden a la DB de
>>> forma concurrente).
>
> "No sé qué problema" >>>> un ejemplo http://personales.unican.es/carreracg/web/filosofos_chinos.html
Ese problema NO se puede dar cuando se accede a una BD. El server DB
ya gestiona la concurrencia, locks, etc para que no ocurran esos
problemas.
ra...@dimension-virtual.com
> El día 24 de marzo de 2011 16:40, Javier Hernández
Por eso decía yo, que me parecía que le fallaba algo de base en la
programación ... solo hay UN caso, vuelvo y repito, SOLO UNO, en el
que puedes necesitar gestionar concurrencia desde la aplicación hacia
un RDBMS, y es el caso de programación asíncrona o multihilo (que no
es lo mismo, ni parecido)
Saludos.
Javier Hernández
pero mira lo tenéis fácil >> http://tinyurl.com/5svd3eu
On 24 mar, 18:43, r...@dimension-virtual.com wrote:
> Iñaki Baz Castillo <i...@aliax.net> escribió:
>
> > El día 24 de marzo de 2011 16:40, Javier Hernández
Javier Hernández
>> programación ...
Graw Hill, O'Reilly, Anaya y compañía. Los temas de creación de
aplicaciones concurrentes, no vienen en los libros BÁSICOS de Java,
vienen en los Avanzados, con los Threads. Además de JNI, EJB,
Hibernate, Spring, JUNIT, Maven, etc...
ra...@dimension-virtual.com
A ver ... que te pones a mear fuera del tiesto y no aciertas ..., yo
solo he dicho, que SOLO hay un caso de programación, en el que está
justificado controlar con semáforos y recursos de ese tipo, el acceso
a otros recursos.
Hoy el día, al que se le ocurra presentarme un programa, que para una
simple tarea como añadir CDR's a una base de datos, me diga que tiene
que implementarlo mediante semáforos para controlar la concurrencia de
accesos a la base de datos ... lo mando directo a la oficina del inem
más cercana.
¿Se puede saber que problemas de concurrencia podrías tener accediendo
a una tabla de cdr's en un RDBMS?, porque a mi no se me ocurre ninguno
y los que se me ocurren ya los soluciona el RDBMS el solito.
P.D.: No presupongas lo que yo sé o dejo de saber, te puedes llevar
una desagradable sorpresa. Pocas, muy pocas cosas he necesitado yo
aprender de esas editoriales que nombras, o de ninguna otra. Los
libros técnicos que consumo, no son sobre temas "generales", como
concurrencia, threads, etc., suelen ser de temas mucho más específicos
que eso, pero de todas formas no es un tema que me parezca que
tengamos que estar hablando aquí.
Saludos
Iñaki Baz Castillo
<javas...@gmail.com> escribió:
>>>Tal vez te refieras a que a nivel de aplicación (Java) no ejecutas una
>>>nueva query SQL si en ese momento hay más de N queries activas en
>>>proceso, lo cuál según el caso podría ayudar a no saturar la BD. Pero
>>>vamos, estoy especulando.
>
> Sí creo que estás especulando, si has leído mis hilos, te fijarás que
> yo no uso SQL, para nada (no se por qué se les ha metido en la cabeza
> eso de SQL), uso HQL.
¿Qué más da? HQL no es más que un SQL vitaminado, no estándar (sólo es
para Java Hibernate) y con cierto mapeo a objetos Java. A efectos
prácticos respecto de lo que estábamos hablando, da igual SQL que HQL.
> Y para consultas complejas, donde hay que filtrar muchos campos, la
> API Criteria (de Hibernate, jBoss (de Red-Hat))
> http://www.javalobby.org/articles/hibernatequery102/
Vale, usas Java, qué guay.
> La ventaja de usar HQL, API Criteria, que no tienes que conocer el
> lenguaje de la BD con la que vaya a trabajar tú aplicación, tu lo
> programas y el mismo código vale para cualquier BD del mercado.
Vale, usas Java, qué guay.
> Desventaja, que tienes que aprender dos nuevos lenguajes.
¿No vale sólo con Java? qué guay.
> En realidad, cuando haces una query Criteria, lo que haces es generar
> una consulta HQL de manera totalmente transparente al programador. Es
> lo más recomendado para hacer consultas grandes como las de las webs
> de viajes que necesitan filtrar por muchos campos.
Vale, usas Java, qué guay.
> Bueno en fin a mi aplicación en Java no le ocurre absolutamente nada,
> todo lo contrario funciona perfectamente, también tiene incluido un UA
> SIP para realizar/recibir llamadas, las coloca en espera y las devía
> seleccionando un destinatario desde una lista desplegable (jComoBox).
> Pero bueno esto son cosas de otros foros/listas, no tiene nada que ver
> con Asterisk, ya no estamos saliendo del tema de la lista (hace rato
> me da). :)
El 95% del 95% de tus correos trata sobre Java. Sí, nos estamos
saliendo del tema de la lista :)
Javier Hernández
Bueno la próxima vez que me tenga que referir a un lenguaje que
utilizo con Asterisk, diré dotNet, para no molestarte.
lo que me da risa es que me lo digas tú a mí, cuando quién comenzó a
desviar el hilo fuístes tú con un churro ahí de MySQL, que yo me
preguntaba ¿y a qué viene esto ahora?. Pero en fin no vamos a estar
con boberías, por mí ya se había acabado pero parece que te gusta.
Si quieres (es una sugerencia), te podrías callar un mes, o un año.
:)
Iñaki Baz Castillo
<javas...@gmail.com> escribió:
> ejeje es como si te molestara Java :)
En absoluto.
> lo que me da risa es que me lo digas tú a mí, cuando quién comenzó a
> desviar el hilo fuístes tú con un churro ahí de MySQL, que yo me
> preguntaba ¿y a qué viene esto ahora?.
Extraido de tu *primer* correo:
-----------------------------------------------------
El problema que tengo es que no me los importa a la tabla cdr de la
base de datos.
En cdr_mysql.conf tengo la ip del servidor mysql y las credenciales,
lo que tengo una duda con sock=/tmp/mysql.sock
-----------------------------------------------------
> Pero en fin no vamos a estar
> con boberías, por mí ya se había acabado pero parece que te gusta.
>
> Si quieres (es una sugerencia), te podrías callar un mes, o un año.
>
> :)
Aplícate eso a ti mismo y nos dejas de dar la tabarra con lo guay que
es Java, que lo que no puede ser es abrir un hilo para hacer una
consulta sobre Asterisk y CDR's en MySQL y añadir luego 30 correos
sobre historietas de Java que no vienen a cuento.
:)
:)
:)
:)
:)
Ramses
--
Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)
~~~ Normas de la lista Asterisk-ES: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://comunidad.asterisk-es.org/index.php?title=Lista:normas-asterisk-es
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Para anular la suscripción: asterisk-es...@googlegroups.com
Javier Hernández
On 24 mar, 23:24, Ramses <ramses.sevi...@gmail.com> wrote:
> Por cierto, y ya que es Viernes, ¿se pueden importar los CDRs a la tabla cdr de una bd MySQL sin JAVA o notNet?
>
> Es aun no me ha quedado claro, y aprovechando que estoy parado en un semáforo... ;-)
>
> Saludos,
>
> Ramses
>
>
>
>
>
>
>
>
> > ejeje es como si te molestara Java :)
>
> > Bueno la próxima vez que me tenga que referir a un lenguaje que
> > utilizo con Asterisk, diré dotNet, para no molestarte.
>
> > lo que me da risa es que me lo digas tú a mí, cuando quién comenzó a
> > desviar el hilo fuístes tú con un churro ahí de MySQL, que yo me
> > preguntaba ¿y a qué viene esto ahora?. Pero en fin no vamos a estar
> > con boberías, por mí ya se había acabado pero parece que te gusta.
>
> > Si quieres (es una sugerencia), te podrías callar un mes, o un año.
>
> > :)
>
> > --
> > Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)
>
> > ~~~ Normas de la lista Asterisk-ES: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Javier Hernández
>
Claro que sí, con Pascal.
Iñaki Baz Castillo
> Por cierto, y ya que es Viernes, ¿se pueden importar los CDRs a la tabla cdr
> de una bd MySQL sin JAVA o notNet?
No, eso no "importa".
> Es aun no me ha quedado claro, y aprovechando que estoy parado en un
> semáforo... ;-)
¿Y cuántos coches concurren en ese semáforo?
Buff, me voy a dormir...
Javier Hernández
http://www.youtube.com/watch?v=z1NZWdNVsfU&feature=related
Buenas noches y Bendiciones!
XD
PD: Ramses, sal ya que el Semáforo hace tiempo que se puso en verde y
ya estás molestando, a los de atrás digo :)
On 24 mar, 23:40, Iñaki Baz Castillo <i...@aliax.net> wrote:
sol...@gmail.com
Es que no me he fijado al compilar si se podía seleccionar en el
menuselect y con eso de que ya los addons vienen integrados...
Ramses
Saludos,
Ramses
Enviado desde mi Móvil
Ramses
Saludos,
Ramses
Javier Hernández
Recording, a mí en adaptive_odbc, odbc, pgsql, radius, sqlite3, sqlite
y tds me aparecen con XXX que significa que no están las dependencias
o existen conflictos.
Lo bueno es que cdr_manager no :) y con eso y Java ya puedo guardar el
cdr de cada llamada junto con todos los datos que recoge la
aplicación, quedó de perlas :)
public void onManagerEvent(ManagerEvent me) {
if (me instanceof CdrEvent){
CdrEvent evento = (CdrEvent) me;
origen = evento.getSrc();
destino = evento.getDestination();
inicio = evento.getStartTimeAsDate();
fin = evento.getEndTimeAsDate();
Saludos
Javier Hernández
Era un ejemplo, no es que lo necesite para eso.
>> el acceso a otros recursos.
On 24 mar, 22:59, r...@dimension-virtual.com wrote:
> Javier Hernández <javaster...@gmail.com> escribió:
Ramses II
MySQL" o no?.
Es que con Java, ha quedado claro, pero sin Java, como que...
Saludos,
Ramses
>-----Mensaje original-----
>De: aster...@googlegroups.com
>[mailto:aster...@googlegroups.com] En nombre de Javier Hernández
>Enviado el: viernes, 25 de marzo de 2011 20:27
>Para: asterisk-es
>Asunto: [Asterisk-ES] Re: Importar los CDRs a la tabla cdr de
>una bd MySQL
>
Javier Hernández
> A ver ... que te pones a mear fuera del tiesto y no aciertas ..., yo
> solo he dicho, que SOLO hay un caso de programación, en el que está
> justificado controlar con semáforos y recursos de ese tipo, el acceso
> a otros recursos.
>>¿Se puede saber que problemas de concurrencia podrías tener accediendo
>>a una tabla de cdr's en un RDBMS?, porque a mi no se me ocurre ninguno
>>y los que se me ocurren ya los soluciona el RDBMS el solito.
Es que no necesito nada de eso.
Javier Hernández
Javier Hernández
>
> ¿Qué más da? HQL no es más que un SQL vitaminado, no estándar (sólo es
> para Java Hibernate) y con cierto mapeo a objetos Java. A efectos
> prácticos respecto de lo que estábamos hablando, da igual SQL que HQL.
>
sirven para .NET y Python. Ya que Hibernate sirve para más lenguajes
que Java. Como .NET o Python e incluso Adobe integra Hibernate en
ColdFusion desde la versión 9.
http://community.jboss.org/wiki/NHibernateforNET
ra...@dimension-virtual.com
> Bueno, ¿pero al final se puede "Importar los CDRs a la tabla cdr de una bd
> MySQL" o no?.
>
> Es que con Java, ha quedado claro, pero sin Java, como que...
>
>
> Saludos,
>
> Ramses
¡Coñe Rames!, ¿no te ha quedado claro que te hace falta un QuadCore a
4Ghz, 6Gm de ram, Oracle 11 y dominar 'oscuras artes' de programación
asíncrona y control de concurrencia para procesar un fichero de log's
y meterlo a una base de datos? ... ¡este niño! ;-)
ra...@dimension-virtual.com
>
>> A ver ... que te pones a mear fuera del tiesto y no aciertas ..., yo
>> solo he dicho, que SOLO hay un caso de programación, en el que está
>> justificado controlar con semáforos y recursos de ese tipo, el acceso
>> a otros recursos.
>
> ¿y quién ha dicho que hayan varios?
Dejalo ya ... que está claro que tienes graves problemas de
comprensión lectora.
>>> ¿Se puede saber que problemas de concurrencia podrías tener accediendo
>>> a una tabla de cdr's en un RDBMS?, porque a mi no se me ocurre ninguno
>>> y los que se me ocurren ya los soluciona el RDBMS el solito.
>
> No se, porque ni siquiera yo me he planteado la pregunta.
>
> Es que no necesito nada de eso.
En tu email original, hablabas sobre los 'posibles' problemas de
concurrencia en el acceso a la tabla de CDR's y sobre eso es sobre lo
que te he preguntado ... y no has contestado, pero es que ya me da
exactamente igual lo que contestes.
Paco Gil
Ramses
> Ramses II <ramses....@gmail.com> escribió:
>
>> Bueno, ¿pero al final se puede "Importar los CDRs a la tabla cdr de una bd
>> MySQL" o no?.
>>
>> Es que con Java, ha quedado claro, pero sin Java, como que...
>>
>>
>> Saludos,
>>
>> Ramses
>
>
> ¡Coñe Rames!, ¿no te ha quedado claro que te hace falta un QuadCore a 4Ghz, 6Gm de ram, Oracle 11 y dominar 'oscuras artes' de programación asíncrona y control de concurrencia para procesar un fichero de log's y meterlo a una base de datos? ... ¡este niño! ;-)
>
> Saludos
Uuuuhhhhmmmm, Rabs, si, ah, vale, vamos, que se puede...
Oye, lo que no entiendo es eso del punto y coma, el guión y el paréntesis que no cierra nada...
Saludos,
Ramses